[Python-Dev] Re: Stability and change

[Guido van Rossum]

>     1) Those people who want to be on the bleeding edge do not, by
>        nature, care what release numbers mean.  They'll work out of
>        CVS repositories, or the similar "snapshot" systems, and can
>        not be convinced otherwise.

In Python's case, that's a vanishingly small fraction of the total
user base.  Even the alpha/beta releases are downloaded by a
disappointingly small number of people.  Many Python users apparently
consider themselves early adopters when they install 2.2 final when it
comes out.

>     2) Those people who care about stability do not, by nature,
>        update frequently, and in fact are often put off by frequent
>        releases.  To them, the more frequent the release, the more
>        indicative it is of bad coding, or instability.

Unfortunately, what's frequent for one person appears at glacial speed
for another.  Since 2.0 came out, we've new Python releases (counting
only the minor version numbers) every 6-8 months.  Apparently the
conservative forces in the community find this too often.

> We can not, while maintaining our collective sanity, please both
> sets of people.  Traditionally, Python has appealed to the 2nd set
> because of its very deliberative nature in the process of adding new
> features.  The PEP process has only further rationalized what was
> unofficial before, and I applaud its structured approach to
> progress.  This appeals to a large group of people who want a
> stable, deliberate progression of releases.

And yet, there is clamoring in the newsgroup that Python changes too
fast, that we add features to minor releases that should deserve a
major release, and that a minor release every 6 months is too often.
So apparently we're not doing enough for these people.

I guess that it means that Python is becoming more popular -- as your
audience grows, it necessarily becomes more conservative (there just
aren't enough early adopters in the world).

> For example, the FreeBSD/OpenBSD projects both use a very similar
> approach in that they have major/minor releases, with the following
> conventions in their numbering scheme:
> 
>     X.Y.Z  for the following...
> 
>     X = Major release, with allowed substantial backward
>         incompatibility
>     Y = Feature release, minimal backward incompatibility, with
>         everything done to avoid these issues.
>     Z = Bug fixes only.  These may break people who have "worked around"
>         the issue, but shouldn't affect 99.999% of the population.

That's what I've always thought the Python version numbering meant
too.  The argument appears to be mostly in the definition of "minimal
backward incompatibility".  *I* though that PEP 285 did everything
humanly possible to make the bool type backward compatible.  But
according to the c.l.py crowd it's not enough.

> The first tenant to releases is that you can not please everyone all
> of the time, most especially people who pay nothing for what they
> receive.  We can make every reasonable effort to avoid backward
> incompatibility, but forward progress necessitates the
> incompatibility at some point.

Try telling Logajan or Rubin that. :-(

> The key to avoiding the pain is to introduce it in stages, that one
> might propose follows the timeline, with the current release X.Y:
> 
>     1) Propose change, formalize specification
>     2) Approve change after review and inclusion of feedback
>     3) Publish change in a prominent location

We do all that.

>     4) Next release X.(Y+1) provides support, but in the __future__
>        mode, and only warns for existing incompatible usage.

It depends on the nature of the feature if that's possible.  A new
type doesn't stay confined to modules that use the future statement;
whenever an instance of it is returned, there's a possibility that the
receiver of that instance is not prepared to handle it.  I can't make
str(True) return something different based on whether the caller has
executed a __future__ statement -- it just wouldn't do the right thing
in too many cases.

>     5) Follow on release X.(Y+2..n) provides for the new state as
>        the default, but allows for the inclusion of old behavior via
>        __past__.
>     6) Next release (X+1).Y drops all support for the previous
>        syntax/cap.  and forces the user to change.

Right on.

> This will allow people who want to migrate to future release without
> upgrading huge code bases to continue to do so.

I sure hope so, but in practice, even the smallest incompatibility
between 2.Y and 2.(Y+1) seems to trip people up.

> One might even envision a site configuration option that would allow
> users to set the default behavior, but then what of those who assume
> differently?

Have multiple versions installed, with binaries named "python2.1,
python2.2, python2.3" and "python" linked to the most popular one.
Bleeding edge users can place a symlink to python2.3 in their personal
bin directory if they don't want to type "python2.3" all the time.

> I will point out that it is trivial to maintain multiple X.Y
> releases on the same machine, and for example, I have 1.5.2, 2.1 and
> 2.2 on my main development machine currently, and simply always make
> sure to specify the Python release in the #! header at the top of
> the file.  This way in the future, I can still use it.

Apparently few people know how to use this properly.  Also, there are
those who want the impossible: they want no old code to break, yet
they want to be able to use bleeding edge packages.

> A panacea of universal happiness is a wonderful thing, but I think
> we need to step back and answer the question of who we are trying to
> please with these proposed changes, whether that group is in fact
> using Python at any large level, or would use Python at any large
> level, and whether or not we would alienate people who have been
> with the community for a large period of time.

This certainly seems closer to resolution that peace in the Middle
East. :-)

> As someone commented (and I can't remember who now), this needs to
> be taken in the context of increasing the spread of Python, rather
> than pleasing a potentially vocal minority.  If such a change is
> advantageous to the spread of Python and its adoption, then I'm 100%
> for it.

Unfortunately, the vocal minority is claiming that Python's fast-paced
releases are what keeps the spread from going up.  Are they right?
Who knows?

> But if it simply cow-tows to "peer pressure," then it seems
> to me that it forsakes progress on the alter of change.  Please
> remember that change and progress are not synonyms.

All in all, I don't think your post has told me anything new.

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