[Python-Dev] Let's get rid of unbound methods

Bob Ippolito bob at redivi.com
Wed Jan 5 04:12:59 CET 2005


On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote:

>
> Tim Peters <tim.peters at gmail.com> wrote:
>> Guido wrote:
>>> Let's get rid of unbound methods. When class C defines a method
> [snip]
>> Really?  Unbound methods are used most often (IME) to call a
>> base-class method from a subclass, like my_base.the_method(self, ...).
>>  It's especially easy to forget to write `self, ` there, and the
>> exception msg then is quite focused because of that extra bit of type
>> checking.  Otherwise I expect we'd see a more-mysterious
>> AttributeError or TypeError when the base method got around to trying
>> to do something with the bogus `self` passed to it.
>
> Agreed.  While it seems that super() is the 'modern paradigm' for this,
> I have been using base.method(self, ...) for years now, and have been
> quite happy with it.  After attempting to convert my code to use the
> super() paradigm, and having difficulty, I discovered James Knight's
> "Python's Super Considered Harmful" (available at
> http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I
> discovered how super really worked (I should have read the documention
> in the first place), and reverted my changes to the base.method 
> version.

How does removing the difference between unmount methods and 
base.method(self, ...) break anything at all if it was correct code in 
the first place?  As far as I can tell, all it does is remove any 
restriction on what "self" is allowed to be.

On another note -
I don't agree with the "super considered harmful" rant at all.  Yes, 
when you're using __init__ and __new__ of varying signatures in a 
complex class hierarchy, initialization is going to be one hell of a 
problem -- no matter which syntax you use.  All super is doing is 
taking the responsibility of calculating the MRO away from you, and it 
works awfully well for the general case where a method of a given name 
has the same signature and the class hierarchies are not insane.  If 
you have a class hierarchy where this is a problem, it's probably 
pretty fragile to begin with, and you should think about making it 
simpler.

-bob



More information about the Python-Dev mailing list