[Python-3000] Generic functions vs. OO

[Phillip J. Eby]

At 10:43 AM 11/23/2006 -0800, Guido van Rossum wrote:
>Changing the class can't add fields to the C struct that represent the
>object (since that would mean realloc()'ing the object and hence
>potentially changing its address). So why not make this a capability
>of the base function type, rather than messing with __class__?

Because it would allow generic function implementations written in Python 
(i.e. using __dict__ for any additional data) to do the same thing without 
needing to much with func_code, the way some of my implementations do now.

The use case for changing the type is allowing functions to only become 
generic once they're *actually* overloaded, so you don't have to go around 
decorating every function as generic "just in case" you want to overload it 
later.  Meanwhile, it would interfere with the "fast track" calling path in 
the interpreter to have generic functions be the same type as regular 
functions.  We'd have to add another check there, like a flag or something, 
so swapping out the type would make it just work with the existing eval 
loop.  (If we later want to have a fast-track for generics, we can always 
check for that new type, too.)

Anyway, all of this implementation discussion is probably premature 
optimization.  My main purpose in allowing delayed overloading is to 
support CLOS-style method combination (or other specialized generic 
function features) on normal functions, without having to predefine the 
original function as being generic.  Of course, changing func_code will 
presumably still work for that, but it precludes the possibility of using a 
C implementation in that case.

But of course all of this is moot unless/until we're actually discussing a 
"real" implementation instead of the proof-of-concept.