[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Wed May 9 23:38:28 CEST 2007
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
>>"Before" and "After" Methods
>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.)
>> from overloading import Aspect
>> class Count(Aspect):
>> count = 0
>> 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.)
More information about the Python-3000