[Python-3000] PEP 3135 (New Super) - what to do?

[Guido van Rossum]

On 6/11/07, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
> Guido van Rossum wrote:
>
> > I'm very tempted to check in my patch even though the PEP isn't
> > updated (it's been renamed from PEP 367 though). Any objections?
>
> Sorry - had to go visit family on the long weekend - only got back late last
> night.
>
> My only objection is the special-casing of the 'super' name - specifically,
> that it *won't* work if super is assigned to something else, and then called
> with the no-arg version.

Well, what's the use case? I don't see that there would ever be a
reason to alias super. So the use case seems to be only semantic
purity.

> But I'm happy to have the changes checked in, and
> look at whether we can fix that without a performance penalty later.

There's the rub -- it's easy to always add a reference to __class__ to
every method, but that means that every method call slows down a tiny
bit on account of passign the __class__ cell.

Anyway, I'll check it in.

> I'll update the PEP when I get the chance to reflect the new direction.
> Ironically, it's now gone back more towards Calvin's original approach (and
> my original self.super recipe).

Working implementations talk. :-)

> So - just clarifying the semantics for the PEP:
>
> 1. super() is a shortcut for super(__class__, first_arg).

Yes.

> Any reason we wouldn't just emit bytecode for the above if we detect a
> no-arg call of super()? Ah - in case 'super' had been rebound. We could
> continue to make 'super' a non-rebindable name.

Believe me, modifying the byte code would be much harder.

I don't like the idea of non-rebindable names that aren't keywords --
there are too many syntactic loopholes (e.g. someone found a way to
bind __debug__ via an argument).

> 2. __class__ can be called directly.

But why should you? It's not there for calling, but for referencing
(e.g. isinstance). Or maybe you meant "__class__ can be *used*
directly." Yes, in that case.

> __class__ will be available in any frame that uses either 'super' or
> '__class__' (including inner functions of methods).

Yeah, but that's only relevant to code digging around in the frame
object. More usefully, the __class__ variable will be available in all
function definitions that are lexically contained inside a class.

> What if the function is *not* inside a class (lexically)? Will __class__
> exist, or will it be None?

It will be undefined (i.e. give a NameError). super can still be used,
but you must provide arguments as before.

I should note that with the current class, while using __class__ in a
nested function works, using super() in a nested function doesn't
really work: while it gets the __class__ variable just fine, it gets
the first argument of the nested function, which is most likely
useless. Not that I can think of a use case for super() in a nested
function anyway, but it should be noted.

> > It is python.org/sf/1727209, use the latest (topmost) super2.diff
> > patch.
> > This would make the new and improved syntax super().foo(), which gets
> > the class and object from the current frame, as the __class__ cell and
> > the first argument, respectively.
> >
> > Neither __class__ nor super are keywords, but the compiler spots the
> > use of 'super' as a free variable and makes sure the '__class__' is
> > available in any frame where 'super' is used.
> >
> > Code is welcome to also use __class__ directly. It is set to the class
> > before decoration (since this is the only way that I can figure out
> > how to generate the code).
> >
> > The old syntax super(SomeClass, self) still works; also,
> > super(__class__, self) is equivalent (assuming SomeClass is the
> > nearest lexically containing class).
>
> Tim Delaney

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