[Python-3000] A super() idea - no _getframe() involved

[Phillip J. Eby]

At 09:06 AM 4/19/2006 +0100, Guido van Rossum wrote:
>On 4/19/06, Phillip J. Eby <pje at telecommunity.com> 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.