[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

Phillip J. Eby pje at telecommunity.com
Thu May 3 18:05:32 CEST 2007

At 10:16 AM 5/3/2007 -0400, Jim Jewett wrote:

On 5/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> I don't doubt that things like @before and @after are > handy. But being handy isn't enough for something to > get into the Python core. I hadn't thought of @before and @after as truly core; I had assumed they were decorators that would be available in a genfunc module.

Everything in the PEP is imported from an "overloading" module. I'm not crazy enough to try proposing any built-ins at this point.

(2) The explicit version of nextmethod corresponds to super, but is uglier in practice, becaues their isn't inheritance involved. My strawman would boil down to...

def foo():... nextmethod = GenFunc.dispatch(*args, after=thisfunction)

Keep in mind that the same function can be re-registered under multiple rules, so a reference to the function is insufficient to specify where to chain from. Also, your proposal appears to be re-dispatching the arguments. My implementation doesn't redispatch anything; it creates a chain of method objects, which each know their next method. These chains are created and cached whenever a new combination of methods is required.

In RuleDispatch, the chains are actually linked as bound method objects, so that a function's next_method is bound as if it were the "self" of that function. Thus, calling the next method takes advantage of Python's "bound method" optimizations.

Note that the overriding function foo would need to have both a reference to itself (as opposed to its name, which will often be bound to somthing else) and to the generic function from which it is being called (and it might be called from several such functions). Arranging this during the registration seems like an awaful lots of work to avoid @after

Yep, it's a whole lot simpler just to provide the next_method as an extra argument.

More information about the Python-3000 mailing list