[Python-Dev] Re: Stability and change

[Alex Martelli]

On Sunday 07 April 2002 03:18, Guido van Rossum wrote:
	...
> [Aahz]
>
> > I'm kind of in agreement with Tim; I don't think this buys much.  Seems
> > more important to me to specify process than stability per se.
>
> I think our process is impeccable.  What's missing is clear guidelines
> for the users.  

I agree with Guido.  I think the issue is first one of perception by users 
and potential users of Python.  I evangelize for Python on a regular basis,
and I notice the issue of _perception_ of stability and change is a
significant block for a certain important category of prospective users.

Basically, users like my previous employer, think3, inc -- "previous"
because, despite it being a great job on many other scores, I grew
frustrated enough with being unable to evangelize Python there, that
I left in February in order to be able to do Python full time.  I had no
problem firing up the enthusiasm of programmers and system
administrators for using Python in scripting, testing and throw-away
tasks -- Python "sells itself" in that way.  But management wants to
see a strategic picture, one with more perspective -- and it wants to
see one of change and evolution within a framework of stability, before
it starts OK'ing a given platform for programs with hundreds or thousands of
function-points.

We had a great opportunity when Microsoft announced the switch of
Visual Basic from VB6 to VB.NET, with lots of enhancements that
would break just about every existing program.  The break with
stability was so large, that even managers with a strong pro-MS
bias were suddenly quite willing to consider alternatives.  I think that
if, at that point, I had been able to point at some implementation that
was both stable _and_ evolving, I might have gotten the OK to do a
pilot project.  "All scripts written 2 years ago still run fine, see, but at
the same time there is active ongoing maintenance -- bug fixes, new
internal speed-ups, new stuff in the library, tools, etc, etc".  I couldn't,
and I couldn't even indicate such a perspective for the future -- each
2.N release would keep breaking some (little, but some) code of
2.(N-1), while 2.N.M would be constrained to absolutely no new
functionality vs 2.N.(M-1), bug-fixes only, assuming there were any
such 2.N.M.  I'm not sure what they are considering now (besides C++,
which dominates there but IS seen as hard and unproductive enough
that the search for higher-productivity languages continues) -- maybe
Java (that got a horrid reputation there due to its instability in '95/'96,
but enough years have passed that they might look at it again now).

"Keep the old interpreter around" is not the solution such prospective
users want to hear.  The choice between being locked off from _all_
enhancements OR having existing code break is what they have with
Visual Basic, say -- exactly the unpleasant choice that makes them
willing to look around for alternatives.  "If you want the bright, new
email package, or to say 'for key in somedict:', you also have to accept
X and Y risks of existing code breakage -- oh and if you don't so
accept it, we'd have to do our own port to the Sharp Zaurus because
the existing one only works for 2.2, and ...", etc, etc.

To some extent this reminds me of another similar frustration of mine,
which was longstanding enough that I had more or less gotten used
to it.  We used to be a multi-platform shop, then switched to releasing
our (mechanical CAD) apps only for Windows OS's, as the wide market
started demanding the ability to use cheap, newly-powerful PCs instead
of costly proprietary workstations.  I kept proposing we do a Linux release
as well, but each time the perception of "the platform changing under us"
(even for the allegedly-stable 2.0.* series etc) was a big factori in
blocking it.  More recently I had had better luck with OpenBSD -- far
stabler than Windows AND actively maintained -- to the point of doing
some minor pilot projects for it.  But in this case the problem was that our
prospective user base had never heard of it (important when choosing
an OS to target, though probably not a language for development) and
would not be well placed to install and maintain it (probably true, it does
require more skill than for Windows or one of the new, friendly Linux
releases such as Mandrake or Suse).  Still, the "stability _and_ change"
paradigm did once again prove quite attractive to management -- they
were at least willing to give OpenBSD a try, as they had not been for Linux.


> Maybe Alex is right and the Linux odd/even distinction
> is clearer than using micro release numbers to indicate bugfix/stable
> releases.

I'm not sure it's clearer.  Clarity may not even matter all that much, as  
long as the message is heard as "there are two parallel lines of
development: one along stable lines, that will break no previously
correct code; one experimental, blazing new trails, for innovation and
higher-risk changes" or something like that.  What I could present
today with integrity is more like "All core developers' interest focuses
on the mildly-experimental track, constrained but only up to a point;
oh yes, there _are_ sometimes bug fix releases to old and stabler
versions, but absolutely no new stuff there -- all new things, even
those which would break no previously correct code, always go into
the mildly-experimental track".

That's not the message the prospective users want to hear, I think.
Not those I have in mind -- substantial software development shops
considering whether to go ahead with Python for very substantial
projects or to relegate it to testing/scripting/throw-away stuff but
never functionality to be delivered to the customer.

> > This way, only major.minor releases can introduce actual language
> > changes, but enhancement releases can pick up library changes.
>
> I don't see how this helps.

It would help to some degree if the "stable" releases could be shown
to have SOME kind of enhancement.  Not as much as if language
changes which did not break existing correct code could also be
there, but some.  Modules such as email are a big part of the draw
of 2.2, for example (not quite as big as language-level enhancements,
but big).


> > Then what we might try for a 2.2.1 release is making the new boolean
> > type a module that people can start using.
>
> No again.  (Banning the new bool type to a separate module is a waste
> of time.)

It would let people "return Boolean.True" where they want to do so
in new parts of their programs while at the same time not worrying
about str(x>y) changing under their feet.  I.e., it would provide, or
be perceived to provide, change within a framework of stability.

Thus it would help us send the message I think prospective users
want to hear -- that Python stands for stability AND change, that
there is not necessarily a contradiction between the two goals.  In
a very minor way, to be sure.


> > I am also a bit amused because an early draft of PEP 6 did try to
> > address this issue, but you and Tim dissuaded me.  I think both of
> > you were right back then, but it's still kind of funny to see it
> > picked up a year later.
>
> We still seem to be disagreeing on how to do it. :-(

More relevantly, I'm not sure I had managed to explain exactly why I
think "stability and change" IS important to Python adoption in a
certain category of software shops.  What numbering or naming scheme
we adopt has importance in determining what we communicate, but
before that, deciding what we DO want to communicate is probably
more important.


> [Barry]
>
> > From my own perspective it seems that 2.1.x is viewed as the stable
> > release family, and each micro release reaffirms its stability.
>
> That's about right.  Maybe we should continue to promote 2.1.x and
> relegate 2.2 to the bleeding edge?  A simple rearrangement of the
> website might be sufficient.

I think such a "retroactive" rebranding of 2.2 as "bleeding-edge" would
be a serious blow to those of us who have accepted it as stable
enough as our base over the last 3 months -- in books, magazine
articles, advocacy within our firms and outside of them, etc.  For
example, AB Strakt has decided 2.2 was stable enough for us (and
it was being presented as such) -- our new code now uses
"for x in somedict:", "if x in somedict:", etc, for example -- now
hearing that it wasn't, and 2.2.X micro-releases might introduce
backwards-incompatible changes, would be a real problem indeed.


> most recently installed version.  (Hm, would it be totally outrageous
> to let Python itself on Windows check for a #! line, and when there is
> one that names an existing Python interpreter that's not the current
> one, simply exec that one on top of the current one???)

It would take away my ability to check if old code still works with a
new release in a simple way -- by explicitly naming the new
interpreter on the command line, whatever is in the shebang line
in the script itself.

> > Or are you just hoping that booleans will be removed in 2.3.1 again
> >
> > :-?
>
> Fat chance. :-)

Indeed -- they won't go.  So, stabilizing on 2.2.* (maybe with Booleans
in a module, but surely no breakage of e.g. str(x>y)) might be one
possibility, if the 2.2.* line was "stable and changing" - introducing
enhancements but not ones that break previously correct code.

I perceive Booleans as small (albeit negatively), but both our CTO and
principal investor have vehemently posted against them, so it would
be hard to 'sell' them even if I were quite favorable.  Still, if that was
the one hurdle to jump to get to a "stable and changing" release, who
knows.  But if jumping that small hurdle only gets to more of the same,
either unstability or feature-frozen versions, the carrot may be too small.


Alex