[Python-3000] [Python-Dev] PEP 367: New Super (original) (raw)

Tim Delaney timothy.c.delaney at gmail.com
Sat May 26 10:13:51 CEST 2007

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. imclassforsuper (imsuper 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 imself 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.imsuper <super: <class 'A'>, NULL>

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

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(, ) returned, rather than 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

More information about the Python-3000 mailing list