[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [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.somemethod) def countaftercall(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 mailing list