[Python-3000] PEP 3124 - more commentary

[Guido van Rossum]

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/)