Backwards Compatibility of Python versions

[Paul Rubin]

"Steve Holden" <sholden at holdenweb.com> writes:
> > If I type "3//4" into 1.5.2 or 2.1, I get a SyntaxError exception, so
> > it isn't backwards compatible.
> >
> Erm, don't you seem to be using a different version of backwards
> compatibilty from most people? As far as I'm concerned, if I run version
> 1.5.2 of a language, and all my programs continue to run, then the new
> release provides backwards compatibility.

Yes, but they DON'T continue to run, then the new release DOESN'T provide
backwards compatibility.

If I write in 2.2 or later 2.x's, I have to choose between two
alternatives, both bad:

 1) use "/" the traditional way.  My programs will then work under 2.1
    and earlier, but they'll break under 3.0 and later.

 2) Use "from __future__ import division" and use // everywhere I
    want traditional integer division.  That means that in the Python
    versions that most people today are actually using, my programs
    won't even parse, let alone run correctly.

> > 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.
>
> Now you are clearly looking for a fight :-) This is bogus. "Current"
> surely refers to "processes the most recent language
> definition". Tim's right, this is rhetorical gimmickry. How
> appropriate your news server is ruckus.brouhaha.com.

I don't agree with you about what "current" surely refers to.  In my
view, "current" refers to whatever is in widespread use at the present
time.  Secondarily, it refers to what the developers are still
maintaining and shipping, which includes 2.1 and (apparently maybe) 1.5.

> > 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 you ever collected stamps, you'd be aware that stamps can be "obsolete"
> (no longer issued) and they may also be "demonetized" (no longer acceptable
> as postage). In the same way, 1.5.2's survival in various Linux
> distributions does not stop it being obsolete. Fortunately it will only be
> "demonetized" (unusable for programming) when there is no longer a platform
> that will allow you to compile to interpreter sources. The open source
> nature of the language means you can continue using 1.5.2 into the far
> future.

But Tim has said there might be a 1.5.3 release.  That means that the
1.5 series is still being "issued" and is not obsolete.  The 2.1
series is definitely still being issued--a new 2.1 release came out
just a few weeks ago, and I believe Tim himself recommended it as the
most stable Python version currently available.  Why on earth would
anyone develop a new 2.1 bugfix release if they thought everyone
should switch to 2.2?

> > 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.
> >
> Nonsense. Do you understand the meaning of the word "currency"? And stop
> relying on the "official Python maintainers" - one of these is Tim Peters,
> and you continue to disagree with him about this matter...

Tim is the one who said there might be a 1.5.3 someday, which is part
of why I refer to the 1.5 series as still current, just like the 2.1
series.  Of course he said it like it (1.5.3) was just a theoretical
possibility rather than something actually likely to happen, so I
won't hold out for that part of "current".  The other part--that lots
of systems still run it--is valid and compelling.

> Coding in a way that requires 2.2 inconveniences *only* those users who a)
> want to use my code *and* b) won't move forward to 2.2.

Even if they're willing to switch to 2.2, making them do so
inconveniences them.  But why should someone be willing to switch to
2.2 today, unless they need the new features for something?  It has a
lot of major rework and I'd rather let the maintainers get the bugs
out before I run production code under it.  I might play with 2.2 at
home, but if I was installing a new production system today, I'd use
2.1.1.

If, someday, there are just a few throwbacks using <= 2.1 (say less
than 10% of all the users), then it will be reasonable to casually use
2.2 features in programs for general distribution.  Right now, it's
probably more like 90% using <= 2.1.  Publishing a script that
requires 2.2 is like publishing a web page that only works with IE6
(or whatever the latest browser is).  It's simply obnoxious to do that
without a good reason.

> I suppose that our writing these posts in English inconveniences
> many of the group's readers for whom English is not the first
> language. They persist in reading them because the benefits outweigh
> the disadvantages (in most cases, anyway, though I'm beginning to
> have my doubts about this particular thread). So, do you want 2.2,
> or 1.5.2. And please *don't* say you want to be able to program 2.2
> features in 1.5.2.

I don't want to use 2.2 features in 1.5.2.  I also don't always get to
choose what version I run, and I almost never get to choose what
version other people run.  On my personal machine I use 2.1.  On
Ruckus (which isn't mine), 1.5.2 is installed and I use that.  Some
other machines I use have even older versions (1.2 or 1.3 from old
Debian releases).

> I still don't see why you want to be able to use "from __future__" in 1.5.2
> programs. What's the point of importing future behavior when you can if you
> also want to run in environments where such behavior isn't available? 

I don't think I asked to use from __future__ in 1.5.2.  Maybe you
didn't understand my request.  I wanted to put something like

   try: from __backward_compatibility__ import old_division
   except ImportError: pass

in all my current scripts.  This is perfectly fine and won't break
anything in 1.5.2 and 2.1.x.  The import will fail and the caught
exception will turn it into a do-nothing.  The request is that in 3.0,
the import should succeed and make my scripts keep working the same
way the did under older versions.

> > 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).
> >
> This *is* purely rhetoric, despite your protestations, until you provide
> evidence.

The evidence is that 2.2 has been out (non-beta) for only about 1 month,
while the older versions have been around for years.  Lots more people
are using the older versions.

> So, what about 1.5.2 and 2.1 programs won't run in 2.2? THOSE features are
> the ones that break backwards compatibility (isn't this where we came in?)
> not the new ones that won't run in older versions.

That is a problem too.

> No. It has been PEP'd for a long time that division breaks in 3.0+,
> and you'd better get used to the idea if you want to move forward
> [in a year or two].

I don't agree with the notion of changing the meaning of basic arithmetic
operators in a supposedly mature language, but at least I can understand
the motivation for it.  I don't see at all why some mechanism can't be
provided to turn off the change ("import from past") just like there's
now a mechanism to turn on the change ("import from future").

> > 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?
> >
> No, you're not even the first person to be so wrong-headed in the way you
> decry the chosen path for the language's development <0.8 wink>. Most unlike
> you, if I might make a personal observation. Just the same, I claim that
> Python supports a *remarkably high* degree of backwards compatibility. Very
> few 1.5.2 programs broke in 2.0, and most of those (from memory) were using
> a non-documented "feature" of the sockets library.

The rand module also disappeared, completely gratuitously as far as I
can tell.  That's what broke the Redhat scripts.

> Hey, under 3.0 you'll be able to redefine __div__ for everything so you get
> exactly the behavior you want. Not sure I'd like to maintain that code,
> though ;-)

Is that for real?  Is there a bad performance hit?  If that makes a
way to keep my scripts working without slowing them down too much,
that might be a reasonable solution.