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

Tim Delaney timothy.c.delaney at gmail.com
Sat May 26 00:16:35 CEST 2007

Bah - this should have gone to Pyton-3000 too, since it's discussing the PEP.

Tim Delaney

Tim Delaney wrote:

Guido van Rossum wrote:

- This seems to be written from the POV of introducing it in 2.6. Perhaps the PEP could be slightly simpler if it could focus just on Py3k? Then it's up to the 2.6 release managers to decide if and how to backport it. That was my original intention, but it was assigned a non-Py3k PEP number, so I presumed I'd missed an email where you'd decided it should be for 2.6. We should probably change the PEP number if it's to be targetted at Py3K only. - 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. - "Calling a static method or normal function that accesses the name super will raise a TypeError at runtime." This seems too vague. What if the function is nested within a method? Taking the specification literally, a nested function using super will have its own preamble setting super, which would be useless and wrong. I'd thought I'd covered that with "This name behaves identically to a normal local, including use by inner functions via a cell, with the following exceptions:", but re-reading it it's a bit clumsy. The intention is that functions that do not have access to a 'super' cell variable will raise a TypeError. Only methods using the keyword 'super' will have a preamble. 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. - "For static methods and normal functions, will be None, resulting in a TypeError being raised during the preamble." How do you know you're in this situation at run time? By the time the function body is entered the knowledge about whether this was a static or instance method is lost. The preamble will not technically be part of the function body - it occurs after unpacking the parameters, but before entering the function body, and has access to the C-level variables of the function/method object. So the exception will be raised before entering the function body. The way I see it, during class construction, a C-level variable on the method object would be bound to the (decorated?) class. This really needs to be done as the last step in class construction if it's to bind to the decorated class - otherwise it can be done as the methods are processed. I was thinking that by binding that variable to PyNone for static methods it would allow someone to do the following: def modulefunc(self): pass class A(object): def func(self): pass @staticmethod def staticfunc(): pass class B(object): func = A.func staticfunc = A.staticfunc outerfunc = modulefunc class C(object): outerfunc = B.outerfunc but that's already going to cause problems when you call the methods - they will be being called with instances of the wrong type (raising a TypeError). So now I think both static methods and functions should just have that variable left as NULL. Trying to get super(NULL) will throw a TypeError. - The reference implementation (by virtue of its bytecode hacking) only applies to CPython. (I'll have to study it in more detail later.) Yep, and it has quite a few limitations. I'd really like to split it out from the PEP itself, but I'm not sure where I should host it. I'll probably come up with more detailed feedback later. Keep up the good work!! Now I've got to find the time to try implementing it. Neal has said he's willing to help, but I want to give it a go myself. Tim Delaney

More information about the Python-3000 mailing list