eppstein at ics.uci.edu
Tue Jul 24 01:12:13 CEST 2001
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/
More information about the Python-list