[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Tue May 15 03:56:33 CEST 2007
At 01:42 PM 5/15/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > If you have only strict precedence
> > (i.e., methods with the same signature are ambiguous), you wind up in
> > practice needing a way to disambiguate methods when you don't really
> > care what order they're executed in
> > ...
> > And, the nature of
> > these observer-ish use cases is that you sometimes need
> > pre-observers, and sometimes you need post-observers.
>This is by far the best explanation I've seen so far of
>the rationale behind @before/@after. It should definitely
>go in the PEP.
>Can you provide a similar justification for @around?
@around is for applications to have the "last word" on how something
should be handled, i.e. to replace or wrap everything else.
>Including why it should go around everything else
>rather than between the @before/@afters and the normal
>Also, why have three things (@before/@after/@around)
>instead of just one thing (@around with a next-method
Because "around" isn't additive, while before and after are. Any
number of before and after methods can be registered for any
signature, because they can't directly interfere with one another
(since they don't directly call the "next" method.
But primary and "around" methods *do* call the next method, so if
they are applying any transformation to the arguments or return
values, they ordering must be predictable and strict. Thus, methods
that can call a next-method (i.e. primaries and arounds) must have a
guaranteed unambiguous precedence. Imagine what would happen if the
results of calling super() depended on what order your modules had
been imported in!
Thus, it's an ambiguity error to define two chainable methods for the
same type signature. Whereas unchained methods like befores and
afters can have as many registrations for the signature as you'd like
More information about the Python-3000