[Python-3000] pep 3124 plans (original) (raw)

Phillip J. Eby pje at telecommunity.com
Fri Jul 27 18:20:30 CEST 2007

At 08:25 AM 7/27/2007 -0700, Guido van Rossum wrote:

Basic GFs, great. Before/after/around, good. Other method combinations, fine. But GFs in classes and subclassing? Not until we have a much better design.

Sounds reasonable to me. The only time I actually use them in classes myself is to override existing generic functions that live outside the class, like ones from an Interface or a standalone generic.

The main reason I included GFs-in-classes examples in the PEP is because of the "dynamic overloading" meme. In C++, Java, etc., you can use overloading in methods, so I wanted to show how you could do that, if you wanted to.

I suspect that the simplest way to fix this in Py3K is with an "overloading" metaclass, as it would not even require any decorators. That is, you could provide a custom dictionary that records every definition of a function with the same name. The actual metaclass creation process would check for a method of the same name in a base class, and if it's generic (or the current class added more than one method), put a generic method in.

With a little bit of work, you could probably determine whether you could get away with dropping the genericness in a subclass; specifically, if all the subclass-defined methods are "more specific" than all base class methods, then there's no need for them to be in the same generic function, unless they make next_method calls. Thus, you'll end up with normal methods except where absolutely necessary.

Such a metaclass would make method overloads look pretty much the same as in OO languages with static overloading. The only remaining hole at that point would be reconciling super() and next_method. If you're using this metaclass, super() is only meaningful if you're not in the same generic function as is used in your base, while next_method() is only meaningful if you are.

I don't know of any quick way to fix that, but I'll give it some thought.

More information about the Python-3000 mailing list