[Python-3000] PEP 3124 - more commentary

[Phillip J. Eby]

At 07:47 PM 5/14/2007 -0700, Talin wrote:
>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.

This isn't so.  Method combination only takes place when a particular 
combination of arguments hasn't been seen before, and the result of 
combination is a single object.  That object can be a bound method 
chain, which is *very* efficient.  In fact, CPython invokes bound 
methods almost as quickly as plain functions, as it has a C-level 
check for them.

In any case, if a method does not have a next-method argument, the 
resulting "combined" method is just the function object, which is 
called directly.

(PEAK-Rules, btw, doesn't incorporate this bound-method-or-function 
optimization at the moment, but it's built into RuleDispatch and is 
pretty darn trivial.)


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

Oh, it's possible all right.  The only tricky bit with the proposal 
under discussion is that I need to know the maximum arity (number of 
arguments) that the function is ever dispatched on, in order to build 
a dispatch tuple of the correct length.  Missing arguments get a 
"missing" class put in the corresponding tuple position.  The rest 
works just like normal type-tuple dispatching, so it's really not that complex.