2.1 vs. 2.2

Terry Reedy tejarex at yahoo.com
Sat Apr 13 19:00:06 EDT 2002


"Jens Baader" <nospam at nospam.com> wrote in message
news:3cb8a755$0$12714$9b622d9e at news.freenet.de...
> I'm downloading Python 2.2.1 right now and I wonder
> why you still produce bugfix releases for the old 2.1 development
line.

Because someone wants it done badly enough (perhaps with encouragement
from others) to volunteer to do it.  Sone of the 2.2.1 bugfixes were
backported from the nascent 2.3 deveopement version.

> It seems that Python 2.2 is somewhat broken.

Hogwash.  Bugfixes were ported from 2.2 back to 2.1 *because* 2.2
fixed a few things that were previous broken.

> If not what's the
> reason that keeps the people from upgrading to 2.2?

Perhaps you should ask before jumping to foolish conclusions.  Some
(overlapping) answers based on newsgroup posts as I remember them:

* Laziness; fatigue; lack of time.

* Lack of perceived positive (>1) benefit/cost ratio.

* Fear of rocking a boat that is sailing fine.

* Non-programmer end users do not care as long as their programs run
ok, so why bother unless forced to by the supplier of the programs
they run.

* Some programmers/businesspeople do not want to force an upgrade on
customers that will not benefit the customers.

* Some programmers do not currently intend or see that they would use
the new features.

* Others might be afraid that they might use the new features if
available, but cannot because of their customer base.

* ???

* ???

> When will we see an official ISO/ANSI standard for Python?

I hope never.  Committee standards are needed when multiple vendors
produce mutually imcompatible (in part) dialects.

> I dislike working with nonstandardized languages.

Then don't.

But notice that there is considerable difference between 'officially'
standardized and standardized in practice.  The cross-platform
portability of single-source-standardized Python is, I believe, as
great or better than some multisource officially-standardized
languages.  Official standards sometimes define features as
implementation-defined (which is to say, not standardized!).  Some
details of Python behavior are 'implementation-defined' precisely
because the same behaviors in C are not standardized and are not (yet)
hidden by current CPython.  There are many other platform and C
variations that have been hidden by Python acting as a standardization
layer.

Terry J. Reedy






More information about the Python-list mailing list