[Python-Dev] Re: Stability and change (original) (raw)

Guido van Rossum guido@python.org
Sun, 07 Apr 2002 18:08:01 -0400

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