Backwards Compatibility of Python versions

[Steve Holden]

"Paul Rubin" <phr-n2002a at nightsong.com> wrote ...
> "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.

But surely your example above is about asking 1.5.2 or 2.1 to do a "//"
operation? Anyway, we can omit all further discussion on *that* topic since
it's clearly not what's foremost in your mind.
>
> 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.
>
Only because you've already decried *the* forward-compatible alternative:

3) Use divmod()[0]

You said "yerch" (or something similar to this), but surely from an
engineering point of view it gets the pragmatic result you want.

[what does "current" mean...]
>
> 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?
>
Tim admitted this as a remote possiblity rather than suggesting it was
probable. As in "there's nothing to stop anyone doing it". Certainly 2.1.2
is the most stable release, but it doesn't implement the current Python
language, whose definition is now implemented by the 2.2 release.

> > > 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.
>
Indeed. So just write in the forwards-compatible subset of 1.5.2, and your
problem goes away.

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

I'd use 2.1.2, but I presume you've just overlooked this January 16 release.
I must be missing something. If I'm not using 2.2 features, I have no need
to switch. So, surely, if I *want* to use those features then I will switch
regardless of the inconvenience.

>
> 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.
>
Aah, "for general distribution". In that case, you are stuck with either
remaining in the forwards-compatible 1.5.2 subset, or distributing the
interpreter with your applications. We can probably agree that while the
latter is practical for large applications (via py2exe of the McMillan
installer, or in the same way Zope does), for smaller programs it simply
carries too much overhead. But I see you wanting the best of both worlds.

> > 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.
>
I was talking about the language definition, you about the interpreter.

> > 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.
>
But a (relatively) minor one. RedHat have stuck with 1.5.2 for rather longer
that was strictly necessary for Anaconda support, they could have updated it
relatively easily but presumably backed off for engineering reasons.

> > 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").
>
Because Guido doesn't feel it will be good for your sanity.

> > > 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.
>
I had overlooked that.

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

Well, I can't see __div__ being removed in 3.0, and it's present in the
language right now. If everything's going to inherit from object in 3.0
maybe there'll be some way to use "rubintegers" instead of the ordinary kind
everywhere. Woudn't bet the farm on it, though: the compiler won't know you
want them in the code it compiles. I was being kind of tongue-in-cheek,
sorry.

regards
 Steve
--
Consulting, training, speaking: http://www.holdenweb.com/
Python Web Programming: http://pydish.holdenweb.com/pwp/