On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote:
Tim Peters <tim.peters@gmail.com> 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
Guido wrote: 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