PEP0238 lament

[David Eppstein]

In article <WV177.36940$Cy.4447774 at news1.rdc1.az.home.com>,
 "Tim Hochberg" <tim.hochberg at ieee.org> wrote:

> Which is not too horrible, but it is extra cruft. So let me turn your
> question around. Can you give an example where you want the type of division
> (float vs floor) to change depending on the type of input (int, float,
> complex)? I can't, although I suspect there must be some. I also suspect
> they're very rare.

Rather than arguing about nonexistent situations, let's make an analogy:
In Python, "123"+"456" = "123456" but 123+456=579.  These are two different 
operators that happen to have the same symbol.  I really don't see why 
integer-division and floating-point-division should be treated any 
differently from this case.

Maybe it would have been more type-safe to have defined a language in which
string concatenation was defined by some other symbol ++, so that 
"123"++"456" would equal "123456" but "123"+"456" would automagically 
coerce the arguments into integers and return 579.  You could argue either 
way on the abstract merits of such a language.  But that's not the language 
we have now, the automagic coercion violates the "better explicit than 
implicit" principle, and there are too many calls to the 
string-concatenation '+' operator to change them without great pain.

Another possible step instead of breaking integer division would be to add 
a warning for any int/float or float/int division, to make it more explicit 
that the two kinds of division are different and that you need to make up 
your mind which one you want to do.  Take out all the automagic and make 
people use explicit casts.
-- 
David Eppstein       UC Irvine Dept. of Information & Computer Science
eppstein at ics.uci.edu http://www.ics.uci.edu/~eppstein/