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

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

More information about the Python-3000 mailing list