Version compatibility in division

Tim Peters tim.one at home.com
Wed Jul 25 23:37:53 CEST 2001


[David Bolen]
> ...
> Then again, the bigger problem with int() is the potential for
> rounding that is, at least theoretically, permitted by the
> implementation, although as someone else pointed out, it's not clear
> that any C libraries actually do that.

Guido suggested that "someone" (certainly me) change Python's implementation
so that int() and long() always truncate, regardless of what the platform C
happens to do.  I can do that, no problem.

There are no known platforms on which that will make a lick of difference,
except to make Python run slower.  But that doesn't mean no such platforms
exist.  And making a particular Python operation run slower can change the
behavior of, e.g., threaded apps.  It's also the case that platforms
certainly vary even now in how int(infinity) and int(NaN) behave (since C89
is silent on those cases), and that they may suffer some different
accidental behavior in these cases after the change.

So is this a change we should be frightened of?  Do we need a

    from __future__ import int_and_long_guaranteed_to_truncate

statement to enable it?

I think that would be absurd, but from an implementer's point of view it's
the plain truth that no change is without consequences.





More information about the Python-list mailing list