[Python-3000] [Python-Dev] PEP 367: New Super
Phillip J. Eby
pje at telecommunity.com
Thu May 31 19:08:40 CEST 2007
At 07:48 PM 5/31/2007 +0800, Guido van Rossum wrote:
>I've updated the patch; the latest version now contains the grammar
>and compiler changes needed to make super a keyword and to
>automatically add a required parameter 'super' when super is used.
>This requires the latest p3yk branch (r55692 or higher).
>Comments anyone? What do people think of the change of semantics for
>the im_class field of bound (and unbound) methods?
Please correct me if I'm wrong, but just looking at the patch it
seems to me that the descriptor protocol is being changed as well --
i.e., the 'type' argument is now the found-in-type in the case of an
instance __get__ as well as class __get__.
It would seem to me that this change would break classmethods both on
the instance and class level, since the 'cls' argument is supposed to
be the derived class, not the class where the method was
defined. There also don't seem to be any tests for the use of super
This would seem to make the change unworkable, unless we are also
getting rid of classmethods, or further change the descriptor
protocol to add another argument. However, by the time we get to
that point, it seems like making 'super' a cell variable might be a
Here's a strategy that I think could resolve your difficulties with
the cell variable approach:
First, when a class is encountered during the symbol setup pass,
allocate an extra symbol for the class as a cell variable with a
generated name (e.g. $1, $2, etc.), and keep a pointer to this name
in the class state information.
Second, when generating code for 'super', pull out the generated
variable name of the nearest enclosing class, and use it as if it had
been written in the code.
Third, change the MAKE_FUNCTION for the BUILD_CLASS to a
MAKE_CLOSURE, and add code after BUILD_CLASS to also store a super
object in the special variable. Maybe something like:
... apply decorators ...
... generate super object ...
Fourth, make sure that the frame initialization code can deal with a
code object that has a locals dictionary *and* cell variables. For
Python 2.5, this constraint is already met as long as CO_OPTIMIZED
isn't set, and that should already be true for the relevant cases
(module-level code and class bodies), so we really just need to
ensure that CO_OPTIMIZED doesn't get set as a side-effect of adding
More information about the Python-3000