features i'd like [Python 3000] ... #3: fix super()
i don't like the current super() at all. having to type super(Foo, self).__init__(...) is messy, hard to remember, and error-prone. 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. 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.) -- as an alternative or in addition, super(args) would work like super.meth(args) if we're currently inside of `meth' in a subclass. i suspect that 90% of the time or more, `super' is used to chain to the superclass version of an overridden method, and this optimizes for the common case. it makes for one less possibility of misspelling `__init__' and one less thing that requires renaming if a method is renamed or code copied to another method (granted, this isn't such a big deal as in the case of class renaming). if the form `super.meth(args)' isn't also supported, then a call of this sort would have to be made through the introspection API. (i think it would be a good idea to have this functionality available through the introspection API, in any case. currently i don't see any obvious way in module `inspect' to find out which class a call to `super(...).meth(...)' is invoked on, although maybe a loop with inspect.getmro() and hasattr() would work. it would be nice to have a function like inspect.getsuper(class, 'meth'), i think.) ben
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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
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
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.
BTW, a "super-only" version of this decortor (that I think could be called "implement") has some more chances in Python. But think belongs more to Python-Ideas list, ok? -- EduardoOPadoan (eopadoan->altavix::com) Bookmarks: http://del.icio.us/edcrypt Blog: http://edcrypt.blogspot.com Jabber: edcrypt at jabber dot org ICQ: 161480283 GTalk: eduardo dot padoan at gmail dot com MSN: eopadoan at altavix dot com
participants (4)
-
Ben Wing -
Eduardo "EdCrypt" O. Padoan -
Nick Coghlan -
Robey Pointer