[Python-ideas] Proposal: Moratorium on Python language changes

[Steven D'Aprano]

On Sat, 24 Oct 2009 04:30:36 pm Stephen J. Turnbull wrote:

> It seems to me that what Guido is heading for here is very similar to
> the "punctuated equilibrium" concept (associated with the
> evolutionary biologist Stephen Jay Gould, the wikipedia article is
> pretty good, and fairly short).  

I argue that you've got it backwards. Python has been relatively stable 
in the ways that matter for almost all of it's history. Nearly all the 
changes to the language in 1.x and 2.x have either been 
backwards-compatible, or managed carefully with a deprecation schedule 
or __future__. The result of this is that code written for Python 1.5, 
and possibly older, will still work in Python 2.6. It's easy enough to 
ignore new features if you need to support an older version.

This does not apply to 3.x. If you want to see punctuated equilibrium in 
software development, the change from 2.x to 3.x is an good example: a 
relatively large change in a non-backwards compatible way, with no 
gentle migration path. Supporting 3.x is all-or-nothing: you can't 
support 3.1 and 2.6 with the same code base, except possibly for the 
most trivial code.

I suggest that the causes of the slow uptake of 3.x isn't too many 
changes to the core, but three factors:

(1) There's no gentle migration path from 2.x to 3.x in the same way 
that there have been gentle migration paths from every version to the 
next version in 1.x and 2.x. Instead you've got a discontinuous change. 
Library maintainers have to choose between:

- support 2.x only
- support 3.x only
- maintain two incompatible code bases.

The path of least effort is to support 2.x only, because they're already 
doing that.


(2) For many people, 3.x doesn't offer any obvious compelling advantages 
over 2.x. (Of course, your mileage may vary.) Reading the What's New 
for 3.0, I see *many* nice features and cleanups, many Nice To Have new 
features, but no obvious Must Have to encourage me to migrate.

http://docs.python.org/dev/3.0/whatsnew/3.0.html


(3) It's the bootstrap problem: most systems that ship with CPython 
still ship with 2.x, and will continue to do so until people are 
regularly using 3.x, but people generally use whatever their system 
ships with.

I don't see that a moratorium on new features will help with any of 
these issues.


> In software, it may make sense to have the stable periods be *much*
> more stable, 

The principle of "release early, release often" argues against that 
claim. The 2.x series has been very successful. Why change a successful 
procedure for one which is, at best, unproven, and at worst, condemns 
the language to the (unfair) label "moribund"?

I don't believe that the experience of the C language is relevant. The C 
*standard* was stable, but actual C compilers evolved like mad, 
providing non-standard features. Because C is so low-level, the 
difference between a built-in and a library is very slight.


> But it makes sense to propose to compress
> the evolution into short periods with many changes, 

As has happened in the change to Python 3.x.


> and have very stable periods of "moratorium" between.

We keep coming back to this idea that the volume of change in a language 
is, in and of itself, harmful. I dispute that. It is *incompatible* 
change that is harmful. Developers have been slow to move to 3.x not 
because it's different from 2.x, but because it is different in 
inconveniently incompatible ways.

There have been some major new features in the 2.x series, e.g. 
new-style classes, generators and decorators. As far as I can tell, 
those versions didn't suffer from lack of uptake as 3.x has suffered. 
It's not new features that frightens developers off, but incompatible 
change.



-- 
Steven D'Aprano