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

[Delaney, Timothy (Tim)]

Guido van Rossum wrote:

>> 1. When a method is defined, the class is bound to it via an
attribute
>> (which in my version is called func_class).

> In Py3k all the func_XXX attrs are renamed __XXX__, so this would be
> __class__; but that's a name reserved for something else, so it would
> need to be something else.  E.g. __containing_class__.

Yep - I've just used a placeholder name.

> Also, this would have to be done when the class is defined; when the
> method is being defined the class doesn't exist yet.

Good point. Change that to "at the first opportunity" ;)

>> 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()

>> 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.

> 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_exam
ples
> .
> 
> 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 ...

Tim Delaney