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

[Phillip J. Eby]

At 01:43 PM 5/12/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > At 01:27 PM 5/11/2007 -0400, Jim Jewett wrote:
> >>If there are two registrations for the same selection criteria, how
> >>can the user resolve things?
>
>But what if there's *already* an @around method being
>used? Then you need an @even_more_around method. Etc
>ad infinitum?

Yep, so simple things are simple, and complex things are 
possible.  That's the Python Way(tm).  :)

To put your comment in another perspective, "but what if somebody 
already defined a method in their class that I want to change?  Then 
I need to subclass it.  And if somebody wants to change that they 
have to subclass *that*, etc. ad infinitum?  Clearly classes are too 
complicated!"  :)

In practice, @around is mostly used for application-defined special 
cases, and there is no higher authority than the application who 
needs to override things.  If a library needs special combinators 
internally, it's better off making them lower-than- at around 
precedence.  Normal, before, and after methods are usually adequate 
for libraries.  (Aside from special-purpose combinators like the 
@discount example.)