At 09:06 AM 4/19/2006 +0100, Guido van Rossum wrote: >On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > Here's how you solve the "how does super() get the current class" problem, > > using existing compiler and VM constructs, and without relying on class > > names, or on functions not being decorated, or anything like that. And > > it's so simple you'll slap your forehead for not thinking of it first. :) > >Actually, I *did* think of it first. :-) > > http://mail.python.org/pipermail/python-3000/2006-April/000947.html > >And no, I didn't use the time machine to plant that. :-)
I read this list via digest, so I hadn't seen it yet. >We could probably >introduce this in 2.6 if the super object, when called, would return >itself; then IMO no __future__ statement would be required since >existing code using super would continue to work. I assume you mean that the compiler would expand super.attr to the magic form, but super() would continue to be old-style. If so, then that still *would* require __future__, since you could legitimately have a variable named super. >Oh, I believe super() also supports static and/or class methods. I'm >not sure how to handle this but I'm sure you can think of something. If super.foobar(args) -> super(ThisClass,firstarg).foobar(args), then it will Just Work(TM) for class methods, since their first argument is the class, and super(someclass,myclass).aClassMethod(...) is the normal way of invoking a superclass classmethod. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
