[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

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
>method.
>
>Also, why have three things (@before/@after/@around)
>instead of just one thing (@around with a next-method
>call).

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