[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun May 13 18:19:36 CEST 2007

At 04:31 PM 5/13/2007 +0200, Christian Tanzer wrote:

"Guido van Rossum" <guido at python.org> wrote:

> - Expect pushback on your assumption that every function or method > should be fair game for overloading. Requiring explicit tagging the > base or default implementation makes things a lot more palatable and > predictable for those of us who are still struggling to accept GFs. Front-up tagging might make it more palatable but IMHO it would be a serious mistake. I still shudder when I think of C++'s virtual (although it's been a looong time since I stopped using C++ [thanks, Guido!] :-)

It's not that serious. Even if we end up with the stdlib-supplied version having to pre-declare functions, it'll be trivial to implement a third party library that retroactively makes it unnecessary.

Specifically, the way it would work is that the overloading.rules_for() function will just need a "before" overload for FunctionType that modifies the function in-place to be suitable.

So, people who want to be able to do true AOP will just need to either write a short piece of code themselves, or import it from somewhere. It'd probably look something like this:

from overloading import before, rules_for, isgeneric, overloadable

@before
def rules_for(ob: type(lambda:None)):
    if not isgeneric(ob):
         gf = overloadable(ob)  # apply the decorator
         ob.__code__    = gf.__code__
         ob.__closure__ = gf.__closure__
         ob.__globals__ = gf.__globals__
         ob.__dict__    = gf.__dict__

The idea here is that if "@overloadable" is the decorator for turning a regular function into a generic function, you can simply apply it to the function and copy the new function's attributes to the old one, thereby converting it in-place. It might be slightly trickier than shown, but probably not much.

More information about the Python-3000 mailing list