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

[Guido van Rossum]

On 5/14/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.)

So you owe us more motivating examples (in addition to the explanatory
examples), showing how you had a particular problem, and you couldn't
solve it cleanly using the usual suspects (subclassing, callbacks,
etc.), and how method combining came to the rescue. Perhaps writing it
up like a pattern description a la GoF might help.

> 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.

Please share more details, so your readers can understand this too.
Right now the whole discussion around this appears to be in your head
only, and what you write is the conclusion *you* have drawn. That's
not very helpful -- I have great respect for the powers of your mind,
but not quite up to the point that I'll accept a feature because you
say it has to be so.

> 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?

You're absolutely free to implement your entire proposal as a 3rd
party library, and then eventually come back and point me to all the
users who are clamoring for its inclusion into the standard library.

> 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.

But can you at least share enough of the problem so others can look at
it and either suggest a solution or agree with your conclusion?

> 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.

I'm all for hooks. They can take the form of a particular factoring
into methods that make it easy to override some method; or using GF's
recursively for some of the implementation, etc.

> (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...)

It should be easy though, because you know which hooks you'll need in
order to add @before and friends...

> 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.

Well, right now I don't care because you haven't shown me the use
case. I could definitely be swayed by a detailed description of a
large use case; much more so than by other arguments I've seen so far.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)