On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
