[Python-3000] pep 3124 plans

[Phillip J. Eby]

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.