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

[Tim Delaney]

Guido van Rossum wrote:

>>> - Why not make super a keyword, instead of just prohibiting
>>> assignment to it? (I'm planning to do the same with None BTW in
>>> Py3k -- I find the "it's a name but you can't assign to it" a
>>> rather silly business and hardly "the simplest solution".)
>>
>> That's currently an open issue - I'm happy to make it a keyword - in
>> which case I think the title should be changed to "super as a
>> keyword" or something like that.
>
> As it was before. :-)
>
> What's the argument against?

I don't see any really, especially if None is to become a true keyword. But 
some people have raised objections.

>> Th preamble will only be added to functions/methods that cause the
>> 'super' cell to exist i.e. for CPython have 'super' in co.cellvars.
>> Functions that just have 'super' in co.freevars wouldn't have the
>> preamble.
>
> I think it's still too vague. For example:
>
> class C:
>  def f(s):
>    return 1
> class D(C):
>  pass
> def f(s):
>  return 2*super.f()
> D.f = f
> print(D().f())
>
> Should that work? I would be okay if it didn't, and if the super
> keyword is only allowed inside a method that is lexically inside a
> class. Then the second definition of f() should be a (phase 2)
> SyntaxError.

That would simplify things. I'll update the PEP.

> Was it ever decided whether the implicitly bound class should be:
>
> - the class object as produced by the class statement (before applying
> class decorators);
> - whatever is returned by the last class decorator (if any); or
> - whatever is bound to the class name at the time the method is
> invoked?
> I've got a hunch that #1 might be more solid; #3 seems asking for
> trouble.

I think #3 is definitely the wrong thing to do, but there have been 
arguments put forwards for both #1 and #2.

I think I'll put it as an open issue for now.

> There's also the issue of what to do when the method itself is
> decorated (the compiler can't know what the decorators mean, even for
> built-in decorators like classmethod).

I think that may be a different issue. If you do something like:

class A:
    @decorator
    def func(self):
        pass

class B(A):
    @decorator
    def func(self):
        super.func()

then `super.func()` will call whatever `super(B, self).func()` would now, 
which (I think) would result in calling the decorated function.

However, I think the staticmethod decorator would need to be able to modify 
the class instance that's held by the method. Or see my proposal below ...

> We could make the class in question a fourth attribute of the (poorly
> named) "bound method" object, e.g. im_class_for_super (im_super would
> be confusing IMO). Since this is used both by instance methods and by
> the @classmethod decorator, it's just about perfect for this purpose.
> (I would almost propose to reuse im_self for this purpose, but that's
> probably asking for subtle backwards incompatibilities and not worth
> it.)

I'm actually thinking instead that an unbound method should reference an 
unbound super instance for the appropriate class - which we could then call 
im_super.

For a bound instance or class method, im_super would return the appropriate 
bound super instance. In practice, it would work like your autosuper recipe 
using __super.

e.g.

class A:
    def func(self):
        pass

>>> print A.func.im_super
<super: <class 'A'>, NULL>

>>> print A().func.im_super
<super: <class 'A'>, <A object>>

> See my proposal above. It differs slightly in that the __super__ call
> is made only when the class is not NULL. On the expectation that a
> typical function that references super uses it exactly once per call
> (that would be by far the most common case I expect) this is just
> fine. In my proposal the 'super' variable contains whatever
> __super__(<class>, <inst>) returned, rather than <class> which you
> seem to be proposing here.

Think I must have been explaining poorly - if you look at the reference 
implementation in the PEP, you'll see that that's exactly what's held in the 
'super' free variable.

I think your proposal is basically what I was trying to convey - I'll look 
at rewording the PEP so it's less ambiguous. But I'd like your thoughts on 
the above proposal to keep a reference to the actual super object rather 
than the class.

Cheers,

Tim Delaney