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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
