[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 11:48 AM 7/23/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > You seem to be saying that the ability to put things in different places
> > encourages disorganization.
>
>No. What I'm saying is that there are conflicting organisational
>requirements here.
>
>If the things being put in different places were independent
>and able to be reasoned about in isolation, everything would
>be fine.

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.


>  But they're not independent, because different
>overloadings of the same GF can interact, sometimes in
>subtle ways, and reasoning about their interactions is
>facilitated by being able to see all the relevant rules
>together.

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

Consider, too, that merely combining super() with multiple 
inheritance can produce very surprising results in today's 
Python.  You cannot statically predict what method super() is going 
to call by looking at the code of the class that calls it.  (Because 
a subclass can effectively insert bases between the class and its 
explicit bases.)

In other words, if you want to know what's going on in a Python 
program today with regard to today's method combination next_method() 
feature (which we call super()), you already have to grep for *all* 
the method definitions.

And this little bit of extra complexity doesn't even have a method 
combination decorator to call out that subtlety to you; you have to 
look in the method *body*.  Even next_method has to at least be 
listed in the argument list.  :)


>Even if the rules don't, in fact, interact, it can be hard
>to convince yourself of this without being sure that you
>simultaneously know what all the rules are at some point
>in time.

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.  That's certainly what I'd do, were I investigating some 
code I was unfamiliar with.  And fancier tools could certainly be 
created, if they were needed.

Python already has each and every one of the things you're 
complaining about, as binary operators depend on multiple argument 
values (and you have to know *both* types in order to work out the 
result), the method being called by super() can't be statically 
predicted any more than next_method(), can, and you already have to 
use grep if you're going after global understanding of a large program.

If anything, generic functions give you *better* tools to work with, 
as there is no trivial way to fire up a program and say, "show me all 
the classes that have a foo() method."  (You could probably write 
something to find them using object.__subclasses__, though, at least 
for new-style types.)