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

Talin 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.

-- Talin

More information about the Python-3000 mailing list