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

[Phillip J. Eby]

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.