Backwards Compatibility of Python versions

[Paul Rubin]

"Tim Peters" <tim.one at home.com> writes:
> > 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.

If I type "3//4" into 1.5.2 or 2.1, I get a SyntaxError exception, so
it isn't backwards compatible.

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

I know this, but 2.1.1 was released more recently than 2.2, so the most
recent release was in the 2.1 series.

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

If the official Python maintainers think they might release a 1.5.3
someday, then it's fair to say that the 1.5 series is still current.
If they're unlikely to ever release another 1.2.x or 0.9.x, then
those versions are not current, even if I release a 1.2.x myself.

More importantly, in the real world, a lot of people are still using
2.1 and 1.5, and few are using 2.2.  So coding anything in a way that
requires 2.2 inconveniences a lot of users.  That might be worth it
for serious features like metaclasses or generators, but is silly to
do over this division nonsense (think of those obnoxious web sites
that tell you to upgrade your browser before you can view some page).

I'd non-rhetorically say that for most users, 1.5.2 or 2.1 is current
and 2.2 is bleeding edge.  (I'm still using 2.1 and plan to get around
to upgrading to 2.1.1).

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

Yes, but we're talking about backwards compatibility (see the thread
header).  "Backwards" from 2.2 means versions like 2.1 and earlier.

Given that 2.2 can import 3.0 division from the "future", will 3.0
have a way to import 2.x division from the "past"?  If I can put

   try: from __backward_compatibility__ import use_old_division
   except ImportError: pass

into all my scripts, and have it maintain the [012].x "/" semantics in
3.0 and later while doing nothing in 2.x and earlier, then that at
least gives me a way to write stable scripts, so I hope 3.0 can
include that.

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

I want my programs to run the same way across the different Python 
versions that people are using now and will be using in the near future.
Am I really the first person to want that?

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

By using divmod(x,y)[0] instead of x/y everywhere I want to divide
ints, per the PEP?  Ugh!