On Fri, 28 May 2010 21:55:28 +0200, cool-RR wrote:
> One person told me that given an unbound method in Python 3.x, it's
> *impossible* to tell to which class it belongs. Is it true?

I believe that that is true.  In Python3 there is no such thing as an
unbound method as a distinct object type.  There are functions, and
there are bound methods.  See the second sentence in this section:

http://docs.python.org/release/3.0.1/whatsnew/3.0.html#operators-and-special-methods

You'll probably have to explain more about the problem you are
trying to solve in order for us to help you find a solution.

--
R. David Murray                                      www.bitdance.com

cool-RR wrote:
> On Sat, May 29, 2010 at 5:46 PM, R. David Murray <rdmurray-2P5OLIWfD11Wk0Htik3J/w@public.gmane.org>wrote:
>
>> On Fri, 28 May 2010 21:55:28 +0200, cool-RR wrote:
>>> One person told me that given an unbound method in Python 3.x, it's
>>> *impossible* to tell to which class it belongs. Is it true?
>>
>> I believe that that is true.  In Python3 there is no such thing as an
>> unbound method as a distinct object type.  There are functions, and
>> there are bound methods.  See the second sentence in this section:
>>
>>
>> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#operators-and-special-methods
>
>
> I see. Where would be a good place to discuss this decision? I would want
> 3.2 to allow pickling of unbound methods.
 

Unbound methods don't exist in Python3. You only have functions and
(bound) methods.

You can see that if you try to call an unbound method with a
non-instance first arg:

>>> class X:
...  def test(self): return 42
...
>>> X.test(X())
42
>>> X.test(3)
42

Doing the same in Python2 gives an error:

>>> X.test(X())
42
>>> X.test(3)

Traceback (most recent call last):

 File "<stdin>", line 1, in <module>
TypeError: unbound method test() must be called with X instance as first argument (got int instance
instead)

On Sat, May 29, 2010 at 18:40, cool-RR <cool-rr-4Sw9Ecu7DfZBDgjK7y7TUQ@public.gmane.org> wrote:
> I see. Where would be a good place to discuss this decision? I would want
> 3.2 to allow pickling of unbound methods.

That would be python-dev <at> python.org

However, it has already been discussed:

 http://mail.python.org/pipermail/python-dev/2005-January/050625.html
 http://mail.python.org/pipermail/python-dev/2007-November/075279.html

It turns out, even the pickling argument was discussed.

 http://mail.python.org/pipermail/python-dev/2005-January/051143.html

Essentially, the argument is that it's easier to use a function
instead of writing a pickler for a method in the first case, so
support for pickling unbound methods isn't a high priority as there
are easier and less magic ways to solve the use case.


I know that's not what you want to hear, but that's likely to be the
answer you'll get.

--
Lennart Regebro

I know that unbound methods are of the function type in Python 3. I'm
calling them unbound methods because they are methods of classes which
are not bound to an instance. I'm aware they have no special stance, but
I still refer to them as unbound methods.

Neglecting reality doesn't help your cause, though. You'll need to understand *why* pickling fails, and then see whether there might be
a solution.

A work-around is to put all methods you want to pickle into module-scope
of your module

class Foo:
 def bar(self):
   pass

bar = Foo.bar

Now you can pickle Foo.bar.

Regards,
Martin