Backwards Compatibility of Python versions
phr-n2002a at nightsong.com
Mon Feb 4 12:13:14 EST 2002
Justin Sheehy <justin at iago.org> writes:
> You don't seem to understand what "backward-compatible" means. What
> you are talking about is more related to forward compatibility, and is
> generally far less important than backward compatibility.
> Backward compatibility is broken when code that does work in an older
> version does not work in a newer version.
The claim was that "from __future__ import division" and using //
stops your old code from breaking when 3.0 comes out, which fits your
definition of backward compatibility. I pointed out that it only
works for 2.2 and later. It doesn't provide backwards compatibility
to the versions of Python that most people actually use today.
> What concrete example do you have of your own working code that was
> correct and working, but broke in 2.2?
I haven't used 2.2 yet. I do hit some snags trying to run 1.5 scripts
under 2.1. They're not my scripts, but that makes it even worse.
If it's my own code, I can usually fix those kinds of problems very
easily. If it's someone else's code, I have to study it and figure
out what it's doing before I can fix it, and still not be sure my fix
> (Note that the "correct" bit there rules out socket-argument problems,
> since the code that broke in those cases was not really conforming to
> the admittedly misleading docs.)
Another culprit is the rand module disappeared. It looks like I can
compatibly replace it with "random", but I'm not sure if there's some
subtle difference that breaks something behind the scenes.
> 2.2 is the only current series, exactly because the Python dev team
> says so. Older versions may receive bugfix releases, but that does
> not make them current.
Excuse me, the Python team can decide things about the Python
language, but it doesn't get to decide about the English language.
"Current" means what users think it means, not what the Python team
thinks it means. If Ford is still selling new Mustangs and releases
improved models of it every so often, then the Mustang is a current
model according to anyone who uses the word in the normal way.
> > 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.
> So, if you don't want to inconvenience those users, don't make your
> code require 2.2. This seems fairly obvious and easy.
But that means I can't say "from __future__ import division", since
only 2.2 and later support that. And if I don't say that, then my
scripts will break in 3.0. How many times do I have to explain this?
> > That might be worth it for serious features like metaclasses or
> > generators, but is silly to do over this division nonsense
> What division nonsense?
> Show me the division-using code that works pre-2.2 but breaks in 2.2.
The breakage will happen in 3.0, not 2.2.
More information about the Python-list