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

[Phillip J. Eby]

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

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

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:

      ...
      BUILD_CLASS
      ... apply decorators ...
      DUP_TOP
      STORE_* classname
      ... generate super object ...
      STORE_DEREF $n

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