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

Alex Martelli aleax@aleax.it
Sun, 7 Apr 2002 10:09:42 +0200

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