[Python-3000] super(), class decorators, and PEP 3115

[Guido van Rossum]

On 4/30/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:17 PM 4/30/2007 -0700, Guido van Rossum wrote:
> >Assuming class decorators are added, can't you do all of this using a
> >custom metaclass?
>
> The only thing I need for the GF PEP is a way for a method decorator to get
> a callback after the class is created, so that overloading will work
> correctly in cases where overloaded methods are defined in a subclass.

I still don't understand why you can't tell the users "for this to
work, you must use my special magic super-duper metaclass defined
*here*". Surely a sufficiently advanced metaclass can pull of this
kind of magic in its __init__ method? If not a metaclass, then a
super-duper decorator. Or what am I missing?

> In essence, when you define an overloaded method inside a class body, you
> would like to be able to treat it as if it were defined with
> "self:__class__", where __class__ is the enclosing class.  In practice,
> this means that the actual overloading has to wait until the class
> definition is finished.
>
> In Python 2.x, RuleDispatch implements this by temporary tinkering with
> __metaclass__, but if I understand correctly this would not be possible
> with PEP 3115.  I didn't make this connection until I was fleshing out my
> PEP's explanation of how precedence works when you are overloading instance
> methods (as opposed to standalone functions).

Correct. As the word tinkering implies, you'll have to come up with a
different approach.

> If PEP 3115 were changed to restore support for __metaclass__, I could
> continue to use that approach.  Otherwise, some other sort of hook is required.

I'm -1 on augmenting PEP 3115 for this purpose.

> The class decorator thing isn't an issue for the GF PEP as such; it doesn't
> use them directly, only via the __metaclass__ hack.  I just brought it up
> because I was looking for the class decorator PEP when I realized that the
> old way of doing them wouldn't be possible any more.

As long as someone's working on it (which I hear someone is), the
class decorator PEP is secure; the actualy discussion was closed
successfully weeks ago.

But I don't understand how a __metaclass__ hack can use a class decorator.

> >I'm not sure that your proposal for implementing an improved super has
> >anything over the currently most-favored proposal by Timothy Delaney.
>
> It's merely another use for the hook, that would save on having another
> special-purpose mechanism strictly for super(); I figured that having other
> uses for it (besides mine) would be a plus.

I'd leave that up to the folks currently discussing super.

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