Backwards Compatibility of Python versions

Mon Feb 4 08:37:17 EST 2002

"Paul Rubin" <phr-n2002a at nightsong.com> wrote in message
news:7xsn8hjxzw.fsf at ruckus.brouhaha.com...
> "Tim Peters" <tim.one at home.com> writes:
> > > 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.
> >
> > Not so:  introducing "//" was 100% backward-compatible, so isn't
controlled
> > by __future__.  "//" works out of the box in 2.2, no __future__
required.
>
> 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.

> > > (The most recently released version of Python is a 2.1 series release,
> > > so 2.1 is still current).
> >
> > I don't know where you're looking, but 2.2 final was released.
>
> 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.

> > Bugfix releases for past versions may (or may not) get released from
> > time to time, but if you decide to build a 1.5.3 someday, that won't
> > make 1.5 "current", it will just make 1.5.3 the most recent release
> > of the 1.5 line (as 2.1.2 is the most recent release of the 2.1
> > line, and contains none of the features new in the 2.2 line --
> > active development of 2.1 ended the day 2.1 final was released, so
> > calling it "current" is rhetorical gimmickry).
>
> 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 that isn't good enough for you, you want new language features, but you
want them to be backwards compatible with 1.5.2. In what strange version of
reality does this make them "new"?

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

> 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.  That might be worth it
> for serious features like metaclasses or generators, but is silly to
> do over this division nonsense (think of those obnoxious web sites
> that tell you to upgrade your browser before you can view some page).
>
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.

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 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? Surely
this means you're going to have to make your programs larger by
incorporating two different algorithms to solve the same problem. Surely it
would be better to set some version flag based on sys.version, then write

if ver152:
    import oldcrap
    mymod = oldcrap
else:
    import snazzynewstuff as mymod

or something similar.

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

> > > 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).
> >
> > The semantics of "/" didn't change in 2.2, and won't in 2.3, 2.4, 2.5,
...
> > either (read PEP 238).
>
> Yes, but we're talking about backwards compatibility (see the thread
> header).  "Backwards" from 2.2 means versions like 2.1 and earlier.
>
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.

> Given that 2.2 can import 3.0 division from the "future", will 3.0
> have a way to import 2.x division from the "past"?  If I can put
>
>    try: from __backward_compatibility__ import use_old_division
>    except ImportError: pass
>
> into all my scripts, and have it maintain the [012].x "/" semantics in
> 3.0 and later while doing nothing in 2.x and earlier, then that at
> least gives me a way to write stable scripts, so I hope 3.0 can
> include that.
>
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].

> > If you need a given static instance of "/" to do
> > radically different things depending on whether you feed it ints or
floats
> > dynamically, you're the first person to claim such a need.
>
> 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.

> > Else you have a specific flavor of division in mind when you type
> > "/", and it's easy to write it in such a way that it will deliver
> > the same results in 3.0 as in 0.9.8.
>
> By using divmod(x,y)[0] instead of x/y everywhere I want to divide
> ints, per the PEP?  Ugh!

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

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