[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
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
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