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

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