[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]
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.
More information about the Python-3000
mailing list