[Python-3000] PEP 3124 - more commentary (original) (raw)

Guido van Rossum guido at python.org
Tue May 15 18:40:28 CEST 2007

On 5/15/07, Phillip J. Eby <pje at telecommunity.com> wrote:

At 08:32 AM 5/15/2007 -0700, Guido van Rossum wrote: >Not so good; I expect the overloads could be written by different >authors or at least at different times. Why can't you dynamically >update the dispatcher when an overloading with more arguments comes >along?

You mean by changing its code? The code to generate the tuple goes in the original function object generated by @abstract or @overloadable. If we can't specify the count in advance, the remaining choices appear to be: * Require *args to be annotated :overloadable in order to enable dispatching on them, or * Only enable *args dispatching if the original function has no explicit positional arguments * Mutate the function Of these, I lean towards the third, but I imagine you'll like one of the other two better. :) If we don't do one of these things, the performance of functions that have *args but don't want to dispatch on them will suffer enormously due to the need to loop over *args and create a dynamic-length tuple. (As shown by the performance tests you did on your tuple dispatch prototype.) Conversely, if we mutate the function, then even dispatching over *args won't require a loop slowdown; the tuple can always be of a fixed length.

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 and eventually add C support to speed it up; that way the Python version can maintain more of the advantages of Python code like readability, maintainability, and evolvability (just in case we don't get it perfect on the first try -- even knowing that it's more like the 3rd try for you ;-).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list