[Python-3000] pep 3124 plans (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Tue Jul 24 02:54:38 CEST 2007

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

More information about the Python-3000 mailing list