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

Phillip J. Eby pje at telecommunity.com
Tue May 15 00:34:20 CEST 2007

At 12:51 PM 5/14/2007 -0700, Guido van Rossum wrote:

On 5/14/07, Phillip J. Eby <pje at telecommunity.com> wrote: > I simply said the plan for Ruby was suggestive that method > combination is worth looking into further, because in the case of > Ruby, they already had single-dispatch generic functions, so the > addition suggests combination is no longer considered a YAGNI there. > > As I said, however, I unfortunately haven't been able to find any > documented rationale for the proposal -- implying that I have no idea > whether Matz' decision is more comparable to jumping off a cliff or > packing a swimsuit, and thus cannot give any actual recommendation > with respect to such. :)

So how do you know what's going on there is the same as what's apparently going on here, i.e. some folks have fallen in love with CLOS or Haskell or whatever and are pushing for some theoretical ideal that has no practical applications?

I don't, which is why I said I'm looking for the RCR or other rationale document.

However, with respect, I didn't go to all the trouble of implementing method combination in RuleDispatch just for the heck of it. (And it was considerable trouble, doing it the way CLOS implements it, until I figured out an approach more suitable for Python and decorators.)

But let me try to get closer to the issue that I have. I honestly don't see at this moment in time, how to split out most of the features you don't like (mainly before/after/around), in such a way that they can be put back in by a third-party module, without leading to other problems. For example, I fear that certain of those features (especially before/after/around) require a single "blessed" implementation in order to have a sane/stable base for library inter-op, even if they could be separated out and put back in. That is, even if it's possible to separate the "mechanism", I think that for "policy" reasons, they should have a canonical implementation.

However, if we posit that I create some "third party" module that should be considered canonical or blessed for that purpose, then what is the difference from simply treating the entire thing as a third-party module to begin with?

I'm not trying to cause a problem here, nor dictate to anybody (least of all you!) how it all should be. I'm just saying I don't know how to solve this bit in a way that works for everybody.

I can go back and spend some more time on the problem of how to separate method combination from the core that I currently envision. But there's going to have to be at least some sort of hook there, to allow it to be added back in later. (Notice that if the core doesn't provide a facility to modify existing functions, then the core has to declare all its hooks in advance. But please don't confuse this statement of fact, with an argument for not doing something I've already agreed to do...)

Anyway, perhaps you don't care if those features can be added back in, or perhaps you actively wish to discourage this. It would be good to know where you stand on this point.

More information about the Python-3000 mailing list