2.1 vs. 2.2

[Martin v. Loewis]

"Jens Baader" <nospam at nospam.com> writes:

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

The main reason is that a really bad bug was found in 2.1.2 which
needed to get fixed.

> It seems that Python 2.2 is somewhat broken. If not what's the
> reason that keeps the people from upgrading to 2.2?

I guess people continue use Python 2.1 for two reasons:
- Zope (or some other package) is certified to work only for Python
  2.1.  If the software author tells you to use Python 2.1, you use
  that because that should cause least problems.
- Python 2.1 is what comes with several systems these days. For example,
  the next Debian release will include Python 2.1 as the default Python
  package; all packages that depend on Python will use 2.1. The rationale
  was that Python 2.2 was not complete at the time when the selection was
  made.

There are some backwards compatibility issues that may cause programs
to break when changing the Python version from 2.1 to 2.2, Andrew
Kuchling recently posted a list of changes he needed to make for his
software. I'd be curious to see similar lists for other packages.

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

Probably never, atleast not in any foreseeable future. Even if people
started to work on an ISO standard today (which nobody currently plans
to), the standard would not be completed before, say, 2004. It takes a
lot of energy to produce such a standard, and nobody is willing to
invest this energy.

> I dislike working with nonstandardized languages.

Why is that?

> The fact that radical language changes are still made (the
> type/class unification) seem to suggest that Python is still not
> mature enough for a real standard.

I'm not sure what a "radical change" is in your view. The new-style
classes of Python 2.3 are a pure extension, not a radical change.

>From a standards point of view, conforming applications would have
continued to work - old style classes have seen no change, and the
only way to tell the difference is to look at the type of some
builtins.

If there was a real standard, it probably would deliberately leave out
implementation details (such as the type of the int builtin), and
merely mandate that it is callable - precisely to give implementations
the liberty to expose proprietary extensions (which newstyle classes
then would have been).

> Or maybe Python and
> the other "newschool" languages (like Ruby, Java) are not
> meant to by standardized? 

Nobody "means a language to be standardized". It is rarely the case
that a language springs into existance by somebody saying: I will
develop a new standard today.

> Don't know but I really would like to.

You would like to what? Develop a Python standard? Just go
ahead. Write it draft standard down, and contact your national
standardization body.

> Are there any plans to get Python "stable" or will the language
> continue to change with each major release of the interpreter?

Python will continue to evolve. Notice that almost every live language
evolves - even if there is a standard for the language.

"Stable" means different things to different people:
- does not break unexpectedly: Both Python 2.1.3 and Python 2.2.1
  are stable in this sense.
- permits to write code that works over a wide variety of
  implementations (ie. versions): Python always did that.
- does not break old applications "suddenly": PEP 5 defines
  the guidelines for language evolution to avoid sudden breakage.
- guarantees that all old applications continue to work the same way
  with all future releases: Python will never be stable in this
  sense, nor do I know any other language that has this property,
  yet provides new features in new versions.

Regards,
Martin