[Python-3000] PEP 3124 - more commentary
talin at acm.org
Tue May 15 04:47:32 CEST 2007
Guido van Rossum wrote:
> Next, I have a question about the __proceed__ magic argument. I can
> see why this is useful, and I can see why having this as a magic
> argument is preferable over other solutions (I couldn't come up with a
> better solution, and believe me I tried :-). However, I think making
> this the *first* argument would upset tools that haven't been taught
> about this yet. Is there any problem with making it a keyword argument
> with a default of None, by convention to be placed last?
I earlier suggested that the __proceed__ functionality be implemented by
a differently-named decorator, such as "overload_chained".
Phillip objected to this on the basis that it would double the number of
decorators. However, I don't think that this is the case, since only a
few of the decorators that he has defined supports a __proceed__
argument - certainly 'before' and 'after' don't (since they *all* run),
and around has it implicitly.
Also, I believe having a separate code path for the two cases would be
more efficient when dispatching.
> Forgive me if this is mentioned in the PEP, but what happens with
> keyword args? Can I invoke an overloaded function with (some) keyword
> args, assuming they match the argument names given in the default
> implementation? Or are we restricted to positional argument passing
> only? (That would be a big step backwards.)
> Also, can we overload different-length signatures (like in C++ or
> Java)? This is very common in those languages; while Python typically
> uses default argument values, there are use cases that don't easily
> fit in that pattern (e.g. the signature of range()).
Well, from an algorithmic purity standpoint, I know exactly how it would
work: You put all of the overloads, regardless of number of arguments,
keywords, defaults, and everything else into a single bin. When you call
that function, you search through ever entry in that bin and throw out
all the ones that don't fit, then sort the remaining ones by specificity.
The problem of course is that I don't know how to build an efficient
dispatch table to do that, and I'm not even sure that it's possible.
More information about the Python-3000