[Python-3000] PEP 3124 - more commentary

[Talin]

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