[Python-3000] PEP 3124 - more commentary
Phillip J. Eby
pje at telecommunity.com
Tue May 15 16:52:28 CEST 2007
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
(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.
More information about the Python-3000