Backwards Compatibility of Python versions

[Tim Peters]

[Paul Rubin]
> ...
> 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.

You misunderstand the bugfix release process:  "the official Python
maintainers" don't do bugfix releases, period.  We haven't had the bandwidth
for it, and it doesn't look like we will.   All bugfix releases have been
produced by community volunteers (2.0.1 was an exception, but was an
artificial release just to get a GPL-compatible according-to-FSF license on
it).  Fred Drake, Barry Warsaw and I have so far been able to put a little
bit of time into doing the last steps of bugfix releases (packaging and
file-uploading and announcing), but that's all.

The odds of getting a 1.5.2 bugfix release are, as for any other bugfix
release, identical to the odds of someone volunteering to produce one.
Guido asked several times for a volunteer to step up, starting about 6
months after 1.5.2 was released.  Nobody bit.  People *have* cared enough to
volunteer bugfix releases for the 2.1 and 2.2 series, which makes claims
about the ongoing vital importance of 1.5.2 to the community suspect.  It's
not that it's old that makes me judge the odds of a 1.5.2 bugfix release
close to zero, it's the years of historical evidence that nobody cares about
it enough to bother.

> ...
> (I'm still using 2.1 and plan to get around to upgrading to 2.1.1).

You should move to 2.1.2 next, then (2.1.1 isn't even "current" by your
definition <wink>).

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

That's a couple years away, so who knows.  My stong guess is no.

...

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

You're the first in a long time to work so hard at misreading <wink>.

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

I don't know:  only you know what your code is trying to achieve.  The only
instances of potential problems we found in the standard library had two
things in common:  (a) it was certain that ints (not longs) were involved,
and (b) it was certain the numerator and denominator were non-negative.  All
such cases can be made version-independent by changing, e.g.,

    h = i / 2

to

    h = int(i / 2)

In practice we *usually* recoded as

    h = i // 2

instead, because there's usually no promise that you can drop a standard
library module from one release into an older release.

If you have messier problems, and you're determined to write code that works
unchanged back through the first Python ever released, then sure -- slicing
divmod is clear and works.  If the clumsiness makes you determined to move
to a more recent release, that's good:  so long as nobody is willing to
maintain older releases, people using them are on their own, and so their
lives are going to get harder as time goes by (e.g., glibc changes in
incompatible ways too over time, so if they ever upgrade their libc, their
old Python may not even compile or link anymore).

OTOH, people "desperately wedded" to an old release are usually stuck there
because of a specific app they rely on, and whether new modules work for
them doesn't really matter.  If "works under 1.52!" were a marketing bullet
point, your market research team would probably decide to devote the ad
space to repetitions of "quantum leap" and "best of breed" instead <wink>.