[Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword

[Guido van Rossum]

On 4/29/07, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:
> Guido van Rossum wrote:
> >> 2. Every non-static method has an implicit cell variable called
> >> 'super'.
> >
> > I think you're using 'cell' in a different sense than it is normally
> > used in Python's implementation. What you are looking for is called a
> > local variable (I deduce this from your initialization of the "cell"
> > with something computed from the first argument).
>
> Actually, I think I'm using the terminology correctly - I'm talking
> about an entry in co_cellvars. Given the following class:
>
>     class A(object):
>         def f(self):
>             super = super_factory()
>
>             def inner():
>                 return 'A' + super.f()
>
>             print inner()
>
> the use of 'super' in both A.f and A.f.inner will produce an entry in
> A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm
> proposing is that the `super = super_factory()` line be implicit in this
> case, resulting in the following code behaving identically:
>
>     class A(object):
>         def f(self):
>             def inner():
>                 return 'A' + super.f()
>
>             print inner()

OK, I see now. I thought you meant for the cell-ness to be related to
the basic implementation; but you meant it so that it woks correctly
inside nested functions. That's fine of course. You might clarify this
somewhere.

> >> The issue of super() vs. super.__call__() ambiguity - I'll need to
> >> look at that when I get home.
> >
> > Sounds irrelevant -- if super is equivalent to
> > __builtin__.__super__(<class>, <firstarg>) then super never gets
> > called; the only thing ever done to it (in the normal course of
> > things) is to request an attribute of it.
>
> Sorry - this is related to my proposal that the following two bits of
> code behave the same:
>
>     class A(object):
>         def f(self, *p, **kw):
>             super.f(*p, **kw)
>
>     class A(object):
>         def f(self, *p, **kw):
>             super(*p, **kw)
>
> But as has been pointed out, this creates an ambiguity with:
>
>     class A(object):
>         def f(self, *p, **kw):
>             super.__call__(*p, **kw)
>
> so I want to see if I can resolve it.

I think the shortcut is more confusing than helpful; I propose to drop
it for the sake of focusing on the essential.

> > super(ThisClass).method(...)  # ???
> >
> > The third exists so that you can create an "unbound" super instance
> > which is useful for the oft-misunderstood autosuper example in my
> > "descrintro" essay:
> >
> > http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exampples
> > .
> >
> > But since the latter is the hack that we're trying to replace with a
> > proper implementation here, I suspect we can get away with only
> > supporting the first two forms (and the third form is still supported
> > using __builtin__.__super__).
>
> Yep - that's my thought as well. I think it would be very rare to need
> super(ThisClass), although it makes some sense that that would be what
> super means in a static method ...

But that doesn't work with the current (2.x) super, and hasn't been
requested AFAIK, so I'd suggest dropping the use case -- KISS again.

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