[Python-3000] super(), class decorators, and PEP 3115
Guido van Rossum
guido at python.org
Tue May 1 00:54:04 CEST 2007
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/)
More information about the Python-3000
mailing list