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

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 imclass 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,1, 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.

More information about the Python-3000 mailing list