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

[Guido van Rossum]

Ouch. You're right. Class methods are broken by this patch. I don't
have time right now to look into a fix (thanks for the various
suggstions) but if somebody doesn't get to it first I'll look into
this in-depth on Monday.

class C:
    @classmethod
    def cm(cls): return cls.__name__
class D(C): pass
print(D.cm(), D().cm())

This prints "C C" with the patch, but "D D" without it. Clearly this
shouldn't change.

--Guido

On 6/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)