On 4 Dec 2006, at 3:13, Nick Coghlan wrote:
Ben Wing wrote:
i don't like the current super() at all. having to type super(Foo, self).__init__(...) is messy, hard to remember, and error-prone.
Yup.
it also introduces an unfortunate dependency in that the name of the class (Foo) has to be hard-coded in the call, and if you change the class name you also have to go and change all super() calls -- more chances for errors. as a result, i imagine there's a strong urge to just hardcode the name of the parent -- a bad idea, and the reason why super() was introduced in the first place.
Also yup.
The fact that these drawbacks are fairly obvious, yet nothing has been done about them should suggest something to you about the difficulty of actually solving this problem in a reliable fashion ;)
The Python Cookbook has a few interesting approaches to making cooperative super calls easier to write, but they all tend to have some kind of drawback that makes them inappropriate for making part of the language core.
instead, `super' should work like in other languages. a couple of ideas:
-- super.meth(args) calls the superclass method `meth', in the same way that super(Foo, self).meth(args) currently works. (this is the same syntax as in java. this probably requires making `super' be a keyword, although it might be possible to hack this by examining the current call stack.)
It's the implementation that's the real sticking point here, so without code this idea isn't likely to go anywhere.
I was bitten by the urge to play with this today, and modified my previous "self" hack to handle "super" also, so that the following code works: class D (C): @method def sum(n): return super.sum(n * 2) - self.base Posted as "evil2.py" here: http://www.lag.net/robey/code/surf/ Because hacking "super" requires having the class object handy, this one needs a metaclass to do its magic, which is a shame. I guess if it was implemented inside the cpython compiler, it would be less of a problem. robey