[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