Backwards Compatibility of Python versions

[Jeff Shannon]

Paul Rubin wrote:

> Would anyone actually WANT to use a 1.5.3 release if it existed?
> (Not that I'm volunteering).  I assume 2.1.2 was done because someone
> wanted to use it rather than switching to 2.2.  But 1.5.anything
> is crufty enough that I'd use 2.1.2 or 2.2 in any new installation.

I suspect that this is the crux of the whole issue.  My personal feeling is that
the only reason anybody *cares* at all about 1.5.2 is because of Red Hat, and
thus, indirectly, the large number of ISP's using it because it's what came with
RH.  Once RH starts shipping with a reasonable Python version (which *ought* to be
with 8.0, whenever *that* comes out, but hopefully *soon*), then 1.5.2 will begin
fading as people upgrade their RH installations.  It probably won't completely
disappear by the time that Python 3.0 is released, but it should be a negligible
concern by then.  At that point, the division change won't be an issue any
more--you'll be able to use the __future__ directive and reasonably expect people
to upgrade if they're running <= 2.2.  In the meantime, you can either use
explicit castings with float() and int(), or plan on having a <= 2.1 version and a
>= 2.2 version.  If you're explicit enough in your documentation/installers/etc
what version is required, and how to get the other version, this shouldn't be too
horrible of a burden.

Jeff Shannon
Technician/Programmer
Credit International