[Python-3000] pep 3124 plans

[Greg Ewing]

Phillip J. Eby wrote:
> ...and may be subclassed in an unlimited number of places.
> 
> A generic function is defined in just one place, with a limited number 
> of "generic" methods typically adjoining it, and may be extended in an 
> unlimited number of places.
> 
> Where's the difference?

With GFs, even if you assume a particular runtime type,
it can *still* be extended in an unlimited number of places.

>> It also provides a convenient mental chunk under which to
>> group all the operations that it implements.
> 
> The function itself is the grouping, in the same way that Python's 
> operator.* functions are, or its built-in generics like len() and 
> iter().

But they're just syntactic sugar for calling methods of the
objects involved, so those objects' classes have full control
of what happens. If len() were a GF in your sense, the code
implementing it for a given type could appear anywhere.

>> No, you're going to find every function whose name is 'foo',
>> whether it's a method of the particular GF you have in mind
>> or not.
>
> And this doesn't apply to normal methods?

Yes, it does to some extent, and that can be a nuisance. But
in the first instance I'm not going to grep the whole program,
just the file where the class is defined. If I don't find it
there, I'll move on to the file defining its base class, etc.
The first definition I find will be the relevant one.

In other words, I have a search *path* through a structure
that's reflected in the layout of the source files. GFs
destroy that structure.

(Multiple inheritance can mess this up a bit, but that just
means multiple inheritance has problems, not that GFs are
good.)

 > For one thing, you can isolate your search to modules that
> import the function being overridden

But I'll still get an unordered set of results that I'll
have to sort through to find the most relevant method.

> The thing that you seem to keep missing in your analysis is that Python 
> already *has* generic functions in the language specification,

But only in a very restricted way -- so restricted that
I've never even thought of them as GFs, but as just another
way to write a method call.

--
Greg