[Python-3000] [Python-Dev] PEP 367: New Super

[Guido van Rossum]

On 6/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:31 PM 6/6/2007 -0700, Guido van Rossum wrote:
> >I wonder if this may meet the needs for your PEP 3124? In
> >particularly, earlier on, you wrote:
> >
> >>Btw, PEP 3124 needs a way to receive the same class object at more or
> >>less the same moment, although in the form of a callback rather than
> >>a cell assignment.  Guido suggested I co-ordinate with you to design
> >>a mechanism for this.
> >
> >Is this relevant at all?
>
> Well, it tells us more or less where the callback would need to
> be.  :)  Although I think that __class__ should really point to the
> *decorated* class, rather than the undecorated one.  I have used
> decorators before that had to re-create the class object, but can't
> think of any use cases where I'd have wanted to use super() to refer
> to the *un*decorated class.

That's a problem, because I wouldn't know where to save a reference to
the cell until after the decorations are done. If you want to suggest
a solution, please study the patch first to see the difficulty.

> Btw, my thought on the keyword and __class__ thing is simply that the
> plus of having a keyword (or other compiler support) is that we don't
> have to have the cell variable cluttering up the frames for every
> single method, whether it uses super or not.

Oh, but the patch *does* have compiler support, and only creates the
cell when it is needed, and only passes it into those methods that
need it.

> Thus, my inclination is either to require explicit use of __class__
> (so the compiler would know whether to include the free variable), or
> to make super a keyword, so that in either case, only the functions
> that use it must pay for the overhead.

My patch uses an intermediate solution: it assumes you need __class__
whenever you use a variable named 'super'. Thus, if you (globally)
rename super to supper and use supper but not super, it won't work
without arguments (but it will still work if you pass it either
__class__ or the actual class object); if you have an unrelated
variable named super, things will work but the method will use the
slightly slower call path used for cell variables.

I believe IronPython uses a similar strategy to support locals() --
AFAIK it generates slower code that provides an accessible stack frame
when it thinks you may be using a global named 'locals'. So again,
globally renaming locals to something else won't work, but having an
unrelated variable named 'locals' will work at a slight performance
penalty.

> (Currently, functions that use any cell variables are invoked more
> slowly than ones without them; in 2.x at least there's a fast calling
> path for code objects with CO_NOFREE, and this change would make it
> useless for everything but top-level functions.)

Not true, explained above.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)