On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 05:55 PM 11/23/2006 +0000, Paul Moore wrote: > >On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > I'm reposting this under a different subject because the other subject > > > seems to have gone off on a tangent. The rest are Phillip's words. > >[...] > > > >OK, I've read and tried to digest this. It looks good. The one thing > >I'm still not getting, at a very concrete level, is precisely what > >changes are required to Python to make it work. > > No changes as such, just additions: > > 1. defop, addmethod/__addmethod__, maybe hasmethod/__hasmethod__ > 2. some generic function implementation that can be applied to "normal" > Python functions > > > > The code is clear > >enough, but it's subtly not Python... For example, the comment "(I am > >assuming here that normal functions are implicitly overloadable, even > >if that means they change type at runtime to do so.)" - I don't > >understand what, if anything this implies about the semantics of the > >"def" statement (assuming that's the statement involved). > > No changes in semantics to "def". I'm just saying that you have to be able > to call: > > addmethod(a_function, methodfunc, a_class) > > And have the existing simple Python function 'a_function' be overloaded as > a result. RuleDispatch and PEAK-Rules do this by replacing the function's > func_code with some newly-generated dispatching code, but if this is to > become a feature of the Python language, it might be better to simply allow > subclassing FunctionType, and let the addmethod operation change the > function's __class__ on the fly. This would allow generic function > implementations to be written in C without additional calling overhead, but > still just modify the original object in-place instead of having to replace > it. > > (You can't just replace the function with a *different* object, because by > the time you overload it, there may be lots of references to it already.) > > It may be that if a_function doesn't have an __addmethod__, then > addmethod() should try to call some special method (__overload__?) on > methodfunc (in case it's been decorated with something that knows how to > turn a_function into a generic function. Finally, if neither side knows > what to do, addmethod() should default to using some built-in or stdlib > generic function implementation.
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__? (This is not an endorsement of the whole thing, which I haven't read yet.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
