Backwards Compatibility of Python versions

[Paul Rubin]

Jonathan Hogg <jonathan at onegoodidea.com> writes:
> > So much for compatibility then.
> 
> I think I missed the beginning of this thread so I'm confused. Exactly which
> new backwards incompatible feature of the recent Python versions is it that
> is breaking people's old scripts?
> 
> So far I've seen complaints of 'x in somedict' which only affects writing
> new code for the new Python interpreter, future division which is not
> enabled yet by default, and the import __future__ mechanism, which again is
> only meant to be called by new code on the new interpreter.

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.  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.  (The most recently released version
of Python is a 2.1 series release, so 2.1 is still current).

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

> If you need to run code on 1.5.2 then don't use any of the new features;
> this is a given. This goes just as much for library evolution as core
> language changes.

> Which *old* code of someone's has actually been broken so that it will not
> run correctly on the newer interpreters?

Redhat installation scripts for one--that may be why they still ship 1.5.2.