[Python-3000] Kill "generic functions"!

Thu Apr 6 21:30:38 CEST 2006

At 10:56 AM 4/6/2006, Guido van Rossum wrote:
>I disagree on principle -- if you were to invent a mechanism to do
>function overloading purely at run-time, then surely you would come up
>with something akin to what we're planning to do here.

The issue is more that Java programmers think they need to use 
staticmethod because that sounds to them like a Java "static method", 
instead of doing something more appropriate like a classmethod or a 
module-level function. I worry that "overloading" will make them 
think it should be used the way it's used in Java, where it often 
substitutes for Java's lack of default arguments. Not only that, but 
overloading in Java means you have to write different implementations 
for different types, even in cases where duck typing would be more 
appropriate. It's especially confusing given Java's mix of 
object-based and non-object numeric types. ISTM that C++ has even 
worse connotations for this.
So, when I say that "overload" has the wrong connotations, I'm not 
talking about some abstract understanding of what it is or does, I'm 
talking about the wrong connotations for their practical intuition of 
how the thing should be *used*. The use cases for overloading in the 
languages that have it are way different, and if you move those 
concepts over to generic functions without a critical 
reinterpretation of the concept, you will write atrocious Python that 
will be hard to read and perform badly.
>And I respectfully disagree. Python's predecessor, ABC, introduced a
>boatload of new terms because they were afraid the traditional terms
>would be misunderstood by newbies. I intentionally didn't borrow any
>of those terms (except list, which I gave a totally different meaning
>:-), going back to traditional terms. I don't want Python to add to
>the language except for the word "Pythonic".

I agree 100% that it doesn't matter what we call it for newbies. My 
point is that it would be much better to *not* have the term's 
familiarity get in the way for the *experienced* people. I want a 
term that we can say is "like overloading, but dynamic", rather than 
just saying it's overloading. Because otherwise it's like that 
psychology experiment where they print the names of colors in colors 
other than the name, and ask people to read them fast. If you see 
the word "brown" and it's actually printed in blue, it's going to 
take you longer to figure out what it says. :) And this happens now 
with things like 'staticmethod', when people blindly apply their 
previous intuitions from other languages.
Anyway, that's my best and only argument, so if you don't agree, I'll 
support "overload". I'll just try to stick in "dynamic" wherever 
possible to help reforming C++ and Java programmers out a bit. :)