method objects vs function objects , Python class instances vs class

Question

I am trying to verify the difference between instance attributes and class attributes as laid out by the Python tutorial release 2.7.3 dated Nov 01, 2012, chapter 9: Classes, Page 66 last line (source):

Valid method names of an instance object depend on its class. By definition, all attributes of a class that are function objects define corresponding methods of its instances. So in our example, x.f is a valid method reference, since MyClass.f is a function, but x.i is not, since MyClass.i is not. But x.f is not the same thing as MyClass.f — it is a method object, not a function object.

I have this:

class MyClass:    
   """A simple example class"""    
   i = 12345   
   def f():    
      return 'hello world'

Then I do this:

>>> x = MyClass()
>>> x.f
<bound method MyClass.f of <__main__.MyClass instance at 0x02BB8968>>
>>> MyClass.f
<unbound method MyClass.f>
>>> type(MyClass.f)
<type 'instancemethod'>
>>> type(x.f)
<type 'instancemethod'>

Note that the type of both x.f and MyClass.f is instancemethod. There is no difference in types but the tutorial says otherwise. Can someone please clarify?

Solution 1

Bound vs Unbound Methods - an explanation.

... or why Python has the behaviour you point out.

So, first off, a note that this is different in 3.x. In 3.x, you will get MyClass.f being a function, and x.f as a method - as expected. This behaviour is essentially a poor design decision that has later been changed.

The reason for this is that Python has the concept of a method that is different to most languages, which is essentially a function with the first argument pre-filled as the instance (self). This pre-filling makes a bound method.

>>> x.foo
<bound method MyClass.foo of <__main__.MyClass instance at 0x1004989e0>>

In Python 2.x and before, it was reasoned that a method not attached to an instance would be an unbound method, which was a function with the restriction that the first argument (self), must be an instance of the object. This is then ready to be bound to an instance and become a bound method.

>>> MyClass.foo
<unbound method MyClass.foo>

With time, it became clear an unbound method is really just a function with this odd restriction that didn't really matter (that self must be of the 'correct' type), so they were removed from the language (in 3.x). This is essentially duck-typing self, which suits the language.

Python 3.3.0 (default, Dec  4 2012, 00:30:24) 
>>> x.foo
<bound method MyClass.foo of <__main__.MyClass object at 0x100858ed0>>
>>> MyClass.foo
<function MyClass.foo at 0x10084f9e0>

Further reading.

This is a (condensed, from memory) explanation which can be read in full from Python creator Guido van Rossum's own mouth in his 'History of Python' series.

Solution 2

The tutorial is indeed wrong; both class.functionname and instance.functionname return a method object.

What goes on is that a function is a descriptor and their __get__ method is invoked, returning a method. Methods have a __func__ attribute pointing back to the original function:

>>> class Foo(object):
...     def bar(self):
...         pass
... 
>>> Foo.bar
<unbound method Foo.bar>
>>> Foo().bar
<bound method Foo.bar of <__main__.Foo object at 0x1090d6f10>>
>>> # accessing the original function
...
>>> Foo.bar.__func__
<function bar at 0x1090cc488>
>>> # turning a function back into a method
...
>>> Foo.bar.__func__.__get__(None, Foo)
<unbound method Foo.bar>
>>> Foo.bar.__func__.__get__(Foo(), Foo)
<bound method Foo.bar of <__main__.Foo object at 0x1090d6f90>>

This all has changed in Python 3 though; there Foo.bar returns the function itself, unbound methods no longer exist:

$ python3.3
Python 3.3.0 (default, Sep 29 2012, 08:16:08) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
...     def bar(self):
...         pass
... 
>>> Foo.bar
<function Foo.bar at 0x105512dd0>
>>> Foo.bar.__get__(None, Foo)
<function Foo.bar at 0x105512dd0>
>>> Foo.bar.__get__(Foo(), Foo)
<bound method Foo.bar of <__main__.Foo object at 0x10552fe10>>

Comments

[astrojuanlu]

Great answer, I learned a couple of interesting things with it.

[haccks]

Tutorial is not wrong. Difference is explained in last para of section 9.3.4 Method objects.

[Martijn Pieters]

@haccks: that doesn't make the statement on that one line correct, however.

[haccks]

That mean you think that there is no difference in function object and method object?

[Martijn Pieters]

@haccks: no, there is a huge difference.

[haccks]

Then the statement: But x.f is not the same thing as MyClass.f — it is a method object, not a function object. is correct IMHO.

[Martijn Pieters]

@haccks: No, because MyClass.f does not return a function object. It is a method object, one without an instance reference so it is unbound.

[Martijn Pieters]

@haccks: type(x.f) is type(MyClass.f) is true. MyClass.f.__func__ is the actual function object.

[haccks]

"a method object is created by packing (pointers to) the instance object and the function object just found together in an abstract object: this is the method object.": that mean an instance object must be passed in order to call a function object while in case of method object, since it is created by packing (pointers to) the instance object (i.e self) and the function object, so no need of instance object as parameter.

[Martijn Pieters]

@haccks: yes, that's what I explain in my answer. Did you read it?

[haccks]

I read it and what I think that tutorial differentiated both on the same basis and that's why I am agreed that the line quoted from tutorial is not wrong.

[Martijn Pieters]

@haccks: I'm sorry, another discussion may have made me a little.. riled. The line in the tutorial states that MyClass.f is a function, while in actual fact that returns a method object too. That's what the question is about, that's what my answer is about. I'm no longer sure what you are asking about however. It doesn't matter what later lines in the tutorial talk about, that one sentence is just incorrect.

[haccks]

No need to riled. I am leaving this discussion now. The reason that I am discussing on a 2 years old post just because that statement was a puzzle for me too and at the end I came to this answer. I already researched on it and my intention was to get that thing correctly, not to argue with you and waste your time. Thanks for your time effort.

[Martijn Pieters]

@haccks: not a problem. I didn't think you were riled, I was saying I was riled by something unrelated and I let that irritation spill over here in my rather curt comment about reading my answer. Sorry!

[haccks]

No. I was not riled. I thought you were irritated and that's why I thought better to quit :)