Backwards Compatibility of Python versions

Paul Rubin phr-n2002a at nightsong.com
Mon Feb 4 19:20:09 EST 2002


"Steve Holden" <sholden at holdenweb.com> writes:
> > No.  I'm taking a practical view of this.  I use HTML tables in my
> > webpages even though there's still a few ancient browsers out there
> > that don't display them.  But if 25% of browsers didn't support them,
> > I'd avoid using them when I didn't need them.  I do avoid making my
> > pages depend on Javascript, for basically that reason.
> >
> "When I didn't need them": surely "must run in old browsers" is not a
> partial requirement. Do you really specify your output format as "must
> remain compatible with Netscape Navigator 2.0 unless it's really important
> not to". No wonder you have problems with the meaning of "backward
> compatibility" <0.9 wink>.

Of course it's frequently a partial requirement, not "must run in old
browsers" but "should run in old browsers unless there's a good reason
not to".  For example,

   http://www.nightsong.com/crypto/dice.php

is a page that uses javascript to do something that can't be done
legitimately without client side scripting (an applet would also
work).  That's a page that does something worthwhile, that won't work
in a non-JS-enabled browser.  (It generates random passphrases from
user-supplied random data).  I used javascript in that page because it
was needed.  That doesn't mean I shouldn't avoid javascript in other
pages where it isn't needed.

> > The question is, what percentage of users are using what Python version?
> >
> Well, if you want to take a count, add me in to the user population of
> 1.5.2, 2.0, 2.1.2 and 2.2. And I think there are a few beta copies lying
> around from pre-2.2. <grin>

Sounds about normal.

> Well, the major problem for most would-be Python software authors right now
> is that Red Hat are still shipping 1.5.2 without any real attempt to conceal
> it from a user wanting to install some later version from the RPMs. 

I think RH 7.2 has Python 2.1 installed as "python2.1" or something
like that.  Running "python" still gives 1.5.2.

> Building their system so it's hard to upgrade Python without
> breaking Anaconda was dumb. Defensible, but dumb. And I think it
> hurts Python more than the benefit of being able to say "Red Hat
> built Python into their system maintenance software."

They read the python web page which claimed that Python was a stable
language and assumed it meant what it said and that their scripts
would keep working.

> I appreciate you are keen to distribute "nifty Python programs". If so, you
> might just have to accept the bloat of building installer versions, untilt
> someone comes up with a way for installers to determine whether Python is
> currently available in an appropriate version or not.

I don't know what I'm going to do about the installer situation.  I'd
like Windows users to be able to use my stuff so I'll probably have
to deal with the installer thing.  Unfortunately (but reasonably) the
installers can only be built on Windows systems, which I currently
don't use.

> These engineering issues are what will stand in the way of Python's
> increasing popularity, which is why I prefer to address them when I see them
> raised rather than ignore them.

I agree with this--among other things, maturity of software means
accepting having to run legacy code and rarely having to tell people
to install new versions of stuff.  

> If you insist that Python isn't backwards compatible, I have to
> think what you must think about VB.NET, where they really *have*
> broken backward compatibility, and in a bug way. Unless VB
> application authors are really careful (and many VB programmers
> aren't familiar with the concept of software engineering) we're
> going to see some really badly broken applications there.

I don't know any specifics about VB.NET or .NET.  I don't use Windows
when I can help it.  To paraphrase Barney Frank, everything about VB
probably violates the sodomy laws of most states ;-).

> By comparison, Python is a hotbed of sanity. So start working on
> 1.5.3 right now. If you ever produce it I'd like to think it would
> get a prominent placed on the website. But remember: with very minor
> exceptions, the rule for bugfix releases is "no new functionality",
> so don't expect to sneak augmented assignments in there, for example!

Would anyone actually WANT to use a 1.5.3 release if it existed?
(Not that I'm volunteering).  I assume 2.1.2 was done because someone
wanted to use it rather than switching to 2.2.  But 1.5.anything
is crufty enough that I'd use 2.1.2 or 2.2 in any new installation.



More information about the Python-list mailing list