[Python-3000] PEP 3124 - more commentary

Phillip J. Eby pje at telecommunity.com
Tue May 15 19:41:53 CEST 2007

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]
                  # 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.

More information about the Python-3000 mailing list