Backwards Compatibility of Python versions

[Tim Peters]

[Paul Rubin]
> That's the problem--if I don't import future division, my code will
> break in the future, because the // operator isn't supported in the
> present.

Not so:  introducing "//" was 100% backward-compatible, so isn't controlled
by __future__.  "//" works out of the box in 2.2, no __future__ required.

>  But if I -DO- import future division, my code will break in
> the present, because current (2.1) and older (1.5) interpreters don't
> recognize the import statement.

2.2 is current; 2.1 and 1.5 are past.

> (The most recently released version of Python is a 2.1 series release,
> so 2.1 is still current).

I don't know where you're looking, but 2.2 final was released.  Bugfix
releases for past versions may (or may not) get released from time to time,
but if you decide to build a 1.5.3 someday, that won't make 1.5 "current",
it will just make 1.5.3 the most recent release of the 1.5 line (as 2.1.2 is
the most recent release of the 2.1 line, and contains none of the features
new in the 2.2 line -- active development of 2.1 ended the day 2.1 final was
released, so calling it "current" is rhetorical gimmickry).

> I don't see any reasonable way I can write code right now that uses
> division that works in both the current 2.1 (which doesn't support
> importing future division) and in forthcoming versions (where the
> semantics of the / operator will be incompatibly different).

The semantics of "/" didn't change in 2.2, and won't in 2.3, 2.4, 2.5, ...
either (read PEP 238).  If you need a given static instance of "/" to do
radically different things depending on whether you feed it ints or floats
dynamically, you're the first person to claim such a need.  Else you have a
specific flavor of division in mind when you type "/", and it's easy to
write it in such a way that it will deliver the same results in 3.0 as in
0.9.8.