[Python-3000] pep 3124 plans

[Greg Ewing]

Phillip J. Eby wrote:
> And that is in fact the *normal* case, even in GF use.  You seem to be 
> arguing that possible == probable, when it simply ain't so.

No, I'm saying that it's hard to convince myself that I'm
not going to fall into one of the possible traps, even if
it's an improbable one.

When adding an overload to a GF, what methodology can I
follow to ensure that my overload doesn't interact in an
unfortunate way with another one somewhere else, perhaps
one not written by me? If the only answer to that is
"grep the entire program for things that might be other
overloadings of this GF", that doesn't do much to allay
my misgivings.

> Yeah, and a program *can* be full of monkeypatching and change classes' 
> __bases__ at runtime, but most people don't write their code that way, 
> most of the time.

The difference is that we're talking about a system
specifically *designed* for carrying out monkeypatching.
I don't care what you call it, it still looks like
monkeypatching to me. The fundamental reason that
we think monkeypatching is a bad idea is still there --
something done by one part of the program can affect
the behaviour of another part with no obvious connection.

> The whole point of GF's is that they make things 
> *simpler*,  because you can usually avoid the sort of awkwardness that
> accompanies trying to do those things *without* GF's.  (E.g. adapters, 
> registries, and the like -- which are just as hard to analyze statically.)

Yes, but as far as I can see, GFs don't make these things
much *easier* to analyse statically. Registries are awkward
because of that difficulty, not because they're hard
to implement.

 > Consider, too, that merely combining super() with multiple inheritance
> can produce very surprising results in today's Python.

Yes, which is largely why I've personally never used super(),
and regard it as a misfeature. I wouldn't mind if it went
away completely.

> Well, as I said before, you can always run the program and dump out the 
> entire list, complete with filenames and line numbers if you're so 
> inclined.

Even once I've got such a list, I've then got to examine it
carefully and try to nut out the implications of all the
type relationships, before/after/around/discount/etc method
cominations, and whathaveyou.

Yes, I know you already get some of this with multiple
inheritance -- which is why I use it very rarely and very
carefully. Also the complexities tend to be confined to the
class doing the multiple inheriting and only need to be
considered by the author of that class, not everyone who
uses it.

And what if the program doesn't exist yet, because I'm
still thinking about how to write it? Or it exists but
isn't yet in a state where it can be run successfully?

 > binary operators depend on multiple argument values (and you
> have to know *both* types in order to work out the result)

Yes, that can be a bit more complex, but at least the method
that gets called has to belong to one class or the other.
Also it's easier to follow nowadays with the auto-coercion
system being phased out -- the left operand gets first say,
and if it doesn't care, the right operand gets its say.

--
Greg