[Python-3000] pep 3124 plans

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. 