PEP0238 lament

[Tim Peters]

[David Eppstein]
> My intuition is that the users who will be surprised that 1/2 = 0 are
> the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.

Anyone using floats will get bitten eventually; ditto anyone using
rationals, for that matter.  This is a "lesser of evils" thing more than a
"good vs evil" thing.

> Result: buggier code since the errors are less obvious.

Perhaps; I don't know of evidence one way or the other, and don't put much
stock in "head arguments" predicting programmer behavior.  I've never heard
that, e.g., Pascal programs were especially prone to numerical bugs (a
language in with 1/2 does return 0.5; and I did work on a vector Pascal
compiler for Cray Research, so it's not that I've heard nothing at all about
Pascal in numeric contexts).  I haven't heard knocks against Algol 60 on
this count either, which for several years was the de facto standard for
publishing numeric algorithms (and in which int/int also returned a real; it
had a different operator for int division).

> If you have a routine "velocity" in which it doesn't make sense to do
> integer truncation, and it doesn't coerce its args to float by
> adding 0.0, that's also a bug.

According to who?  Routines are often *used* in ways authors didn't
anticipate, and a dynamic language (like Python) encourages that.  The
current rules for "/" work against it.