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

[Phillip J. Eby]

At 02:41 PM 5/9/2007 -0600, Steven Bethard wrote:
>On 4/30/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>Proceeding to the "Next" Method
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>[snip]
>>"Before" and "After" Methods
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>[snip]
>>"Around" Methods
>>~~~~~~~~~~~~~~~~
>[snip]
>>Custom Combinations
>>~~~~~~~~~~~~~~~~~~~
>
>I'd rather see all this left as a third-party library to start with.
>(Yes, even including __proceed__.)

That'd be rather like adding new-style classes but not super().


>It shouldn't be a problem to supply these things separately, right?

Separating proceed-ability out would be tough; every function that 
wanted to use it in any way would need additional decoration to flag 
that it wanted to use an alternative base method implementation.

Meanwhile, for the rest of the features, most of the implementation 
would still have to be in the core module.  The method combination 
framework has to exist in the core, or it can't do method combination 
without essentially replacing what's *in* the core, at which point 
you're not really *using* it any more.  That is, you'd just be using 
the third-party library.

In other words, no, you can't take out all forms of method 
combination (which is essentially what you're proposing) and still 
have the ability to add it back in later.

Meanwhile, leaving in the ability to have method combination later, 
but removing the actual implementation of the @before/around/after 
decorators in place would delete a total of less than 40 non-blank 
lines of code.  Removing __proceed__ support would delete maybe 10 
lines more, tops.

Given that removing the 40 lines removes an excellent example of how 
to use the combination framework, and removing the 10 imposes 
considerable difficulty for anybody else to put them back, it seems 
unwise to me to take either of them out.  That is, I don't see what 
gain there is by removing them, that wouldn't be equally well 
addressed by splitting documentation.

(These lines-of-code estimates are based on what's in 
peak.rules.core, of course, and so might change a bit depending on 
how things go with the PEP.)


>>Aspects
>>-------
>[snip]
>>      from overloading import Aspect
>>
>>      class Count(Aspect):
>>          count = 0
>>
>>      @after(Target.some_method)
>>      def count_after_call(self, *args, **kw):
>>          Count(self).count += 1
>
>Again, I'd rather see this kind of thing in a third-party library.

The reason for it being in the PEP is that it benefits from having a 
single shared implementation (especially for the weakref dictionary, 
but also for common-maintenance reasons).  Also, the core's 
implementation of generic functions will almost certainly be using 
Aspects itself, so it might as well expose that implementation for 
others to use...


>Summary of my PEP thoughts:
>* Keep things simple: just @overload, @when, @abstract and Interface.
>* More complex things like __proceed__, @before, @after, Aspects, etc.
>should be added by third-party modules
>
>As others have mentioned, the current PEP is overwhelming. I'd rather
>see Py3K start with just the basics. When people are comfortable with
>the core, we can look into introducing the extras.

Naturally, I don't consider any of these items "extras", or I 
wouldn't have included them.  The "extras" to me are things like full 
predicate dispatch with pattern matching and variable binding, 
ordered classifiers, parsing combinators (i.e. using overloads to 
define grammar productions), custom implication precedence, custom 
predicate indexes, and all that sort of thing.

What's proposed in the PEP is a far cry from being even as expressive 
as CLOS or AspectJ are, but it does supply the bare minimum needed to 
create a foundation for other libraries to build such capabilities on it.

(Btw, a side data point: Ruby 2.0 is supposed to include method 
combination; specifically ":pre", ":post", and ":wrap" qualifiers 
modeled on CLOS's "before", "after", and "around", respectively.)