[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Tue May 15 00:02:42 CEST 2007
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.
More information about the Python-3000