Version compatibility in division

[David Bolen]

"Tim Peters" <tim.one at home.com> writes:

(changing int()/long() to truncate)

This post is mostly tongue-in-cheek...

> 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.

Of course, this isn't the best example, since threaded apps by their
nature must be written to be safe in such variations, and a given
platform on a given day might vary timing of the application even
without changes.

>                                    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.

Now, that could be a compatibility argument, but only if the existing
behavior were well defined.  I don't think compatibility needs to be
inclusive of undefined behavior - if the old platform said that some
behavior was undefined, then no change really violates that.  The
largest concerns for compatability should be concerned with conforming
to pre-existing definitions of behavior and interfaces.

Sure, some old code might just happen to work if the behavior was
lucky for the code, but that's a hard argument to care about breaking.

> 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.

Agreed (to both points).  But it's probably realistic to consider that
changing any existing feature (or even a functional interface) such
that previously defined behavior changes, will probably require some
such support for the change.

Of course, that leaves a whole wide range of stuff that either changes
undefined behavior, or just adds behavior.

And as I've said before, clearly some pragmatism can come into play
such that changes can be judged on a case by case basis.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/