[Python-Dev] Re: Stability and change

[Guido van Rossum]

Alex, please try brevity. :-)

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

Now there's a good proposal.  But it costs time and effort that takes
away from our main mission (and PythonLabs is already under a lot of
pressure).  I wonder if there's a commercial market for this?  Maybe
ActiveState could back-port important packages or language changes and
insert them into ActivePython?

[proposal to semi-backport bool snipped]
> 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.

Given the requirements you give elsewhere in your message, I'm not
sure how to satisfy all these constraints.  Let's be concrete.  Should
we backport stuff to 2.1 (the earliest release I'm willing to
consider)?  If so, what?  Look at the "What's New?" section in
http://www.python.org/2.2/.  The new Windows installer has already
been backported to 2.1.  Type-class unification is obviously out.  So
are interators and generators (too much effort).  So is // division (I
think).  Returning longs instead of raising OverflowError on int
operations would probably break too much code, so it's better not to
backport.  That leaves the email package and xmlrpclib (both available
as separate distros!), and large file support -- which I believe *did*
get ported to 2.1.2.

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

Unfortunately, it's not clear what adaptation in that (apparently very
change-resistant) category buys *Python*.  IOW why should we, mostly
volunteers working for the community, care?

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

Indeed.  But I'd love it if all we need to do is change our
communication patterns, because that takes much less effort than fully
maintaining two separate release tracks.

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

I'm happy to hear that 2.2 is stable for you -- exactly as I
intended and expected.  But what confuses me is that while you're
happy with 2.2's stability, you don't want to testify of this fact to
the more conservative shops.  Rather than telling them "honestly, I
cannot recommend 2.2", why don't you tell them "I've used 2.2 for
three months and it's as solid as a rock"?

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

If I didn't suspect that you, the CTI and the P.I. together are 75% of
the company, I would say that they are micromanaging you. :-)

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

I suspect that the people who complain that Python's rate of change is
too fast are misguided.  There's a lot of fuss on the newsgroup about
potentially breaking code and undesired changes, and before you know
it, everybody just *believes* that Python is unstable and changes too
fast.  But if you try it, you find very little incompatibility, and
what's there is easily dealt with.  The people on the newsgroup who
complain that the introduction of bool is such a major change that it
would only be acceptable in a major release (i.e. 3.0) vastly
overestimate its impact, which is minuscule (zero in most cases).

Logajan's main gripe (and also McMillan's biggest effort in keeping
his codebase cross-version portable) was about things that changed
between 1.5.2 and 2.0 -- that *was* a major release.  And at the time
we didn't have PEPs 4-6, there was no warning module, and so on.

So maybe there's only (or mostly) a problem of *perception*?

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