At 09:40 AM 5/15/2007 -0700, Guido van Rossum wrote: >It looks like you're focused ion an implementation that is both highly >optimized and (technically) pure Python (using every trick in the >book). Personally I would rather go for a a slower but simpler pure >Python implementation
Actually, the need to handle keyword arguments intelligently pretty much demands that you use a function object as a front-end. It's a *lot* easier to compile a function that does the right thing for one specific signature, than it is to write a single routine that interprets arbitrary function signatures correctly! (Note that the "inspect" module does all the heavy lifting, including the formatting of all the argument strings. It even supports nested tuple arguments, though of course we won't be needing those for Py3K!) IOW, I originally started using functions as front-ends in RuleDispatch to support keyword arguments correctly, not to improve performance. It actually slows things down a little in RuleDispatch to do that, because it adds an extra calling level. But it's a correctness thing, not a performance thing. Anyway, I've figured out at least one way to handle *args efficiently, without any pre-declaration, by modifying the function template slightly when *args are in play: def make_function(__defaults, __lookup, __starcount): def $funcname(..., *args, ...): if args and __starcount: # code to make a type tuple using args[:__starcount] else: # fast code that doesn't use __starcount def __setcount(count): nonlocal __starcount __starcount = count return $funcname, __setcount This avoids any need to mutate the function later; instead, the dispatch engine can just call __setcount() when it encounters signatures that dispatch on the contents of *args. So, I think this will do everything you wanted. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com