[Python-Dev] "Unstable" is an ambiguous word...

[Guido van Rossum]

> The Python language was not 'stable' between 2.1.* and 2.2 : some
> previously correct programs stopped working.  That's according to
> plan.  BUT -- that plan is a problem for people who need their code,
> if correct, to keep working for longer than the 6 months between
> minor releases.  Right now we're telling them to stick with (e.g.)
> 2.1 and just hope that somebody is interested enough to backport
> bug fixes, enhancements that would break nothing (such as new
> library modules) or "nothing important" (a far harder call!-), and
> so on.  I do not think this is optimal.

Maybe not, but it works pretty well in the one case I'm familiar with,
Zope.  We recommend using Python 2.1.2 (and as of tomorrow, 2.1.3) for
Zope 2.4 and 2.5, and probably also for Zope 2.6 once it's out.

> On one hand it may over-constrain Guido from release to release.
> He can't put a feature in 2.3 without thereby befoming unable to take it
> away again, or redo it in some incompatible way, should it prove 
> imperfect.  If 2.3 was an admittedly experimental release, he COULD
> choose to take more risks in this sense!

Maybe, but in practice, any major new feature (say, of the level of
list comprehensions or augmented assignment) takes too much effort to
add lightly, and once it's there, it's too enticing not to start using
in the standard library -- and then I can't take it away at all.  At
best, I'll be able to tweak it a bit (which is better than now,
admittedly).

> He may afford a little bit less stability in the design of languages
> he releases (not necessarily in terms of "it crashes every minute"
> -- that's ANOTHER sense of "stable"... the one I was mentioning 2
> para's ago, and the one I think you're asking about).
> 
> On the other hand, software dev't managers don't like the choice
> between an "old, obsolete, probably not of interest any more" piece
> of software, and one that's "so brand-new it's still churning AND
> may break your existing correct code".

But that's still the choice they get, albeit phrased differently.

> It seems to me that trying to reasonably meet all needs within one
> "track" of development is doomed to fail, while "two tracks" would
> afford a better chance.  The "stable" track would focus on not
> breaking existing correct programs; the "experimental" track would
> focus on enhancements with more freedom (including freedom to
> take some language-design risks).

I'm not sure the stable track would differ in practice from what we're
already doing with 2.1.3 and 2.2.1.

> Thus, "who decides" would have to be GvR -- but it woulnd't most
> likely be twice a year that the stable track gets to a head  and
> needs a new baseline (stabilized from a line of experimental
> track releases).  The lucky accident of 1.5.2's long stability, which
> attracted so many to Python, would ideally be reproduced by
> design... or so one can hope.

I don't know that 1.5.2's stability attracted people.  It was probably
more its feature-fullness, plus the fact that around the same time
lots of books etc. started to appear.

--Guido van Rossum (home page: http://www.python.org/~guido/)