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

[Phillip J. Eby]

At 03:43 PM 5/14/2007 -0400, Jim Jewett wrote:
>On 5/14/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>I don't see what the benefit is of making people implement their own
>>versions of @before, @after, and @around, which then won't
>>interoperate properly with others' versions of the same thing.  Even
>>if we leave in place the MethodList base class (which Before and
>>After are subclasses of), one of its limitations is that it can only
>>combine methods of the same type.
>
>That sounds broken; could you use a numeric precedence with default
>levels, like the logging library does?

There are lots of things that *could* be done, but I personally 
dislike numeric levels because they're arbitrary and it's too easy to 
just tweak a number than think through what you actually intend.

However, nothing stops you from inventing a combination type or even 
a criterion type that uses a numeric precedence.  However, at this 
point, just to prevent further head-exploding I've been leaving that 
part of the extension API vague.

But, the basic idea is that just like Interfaces or ABCs or Roles can 
be used to annotate arguments, so too could you add other types of 
criteria objects, and the precedence of those criteria could be used 
to disambiguate method precedence.

In other words, you're not limited to using diffferent combinators in 
order to extend the precedence system.  That's just what we've been discussing.

One of the reasons to have standard versions of 
when/before/after/around, however, is so that most code will never 
need to define any combinators.  The standard ones should handle the 
vast majority of use cases.

Admittedly, before/after/around are IMO 20% cases, not 80% 
cases.  Probably basic overloading is 75-80% of use cases.  But 
before/after/around covers another 20-25% or so, leaving maybe 5% or 
less for the custom combinator cases.