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

Alex Martelli aleax@aleax.it
Mon, 8 Apr 2002 21:49:28 +0200

On Monday 08 April 2002 21:26, Guido van Rossum wrote: ...

> True, and yet such decision makers DO want to perceive that the > specific software they use IS actively supported. It's a reasonable > desire indeed, as I've tried to explain quite a few times.

Yet it is close to Logajan's position.

I dispute that, even though he himself appears to be judging from one post he made to c.l.p -- which I answered trying to dispell his false hopes in the matter. He wants to ensure that software that runs on (e.g.) 2.(N+1) must also have run on 2.N : this is unreasonable, and I've never heard anybody else ask for that. He also seems to want this to hold across major release number changes, 1.* to 2.* -- and again that does not seem to be a widespread priority.

> If they perceive that choosing "Python in general" means they have > to choose between an "old, not actively supported any more" version > of the language, and one that breaks previously working code every > six months, then that will weigh on their mind as a big minus for > Python.

So it's purely a matter of spin. Because new Python releases every 6 months do not mean that code breaks every 6 months. Yet some people continue to believe this.

I may be wrong, but I think that the fact that doctests DO break with every release has something to do with this perception. doctest is SO nice, easy and natural to use (within a single release) that it's hard to accept it as "unusable between minor releases", even though I have to reluctantly accept that decision.

> If they perceived they could choose a "stable but actively > supported" version (the existence of an experimental one too would > not worry them, I believe -- many popular languages sprout > experimental ones based on them too) then that worry would be out of > the way, and I'd have a better chance to get them to LOOK at the > huge productivity improvements Python has in wait for them...

Maybe all we need to do is make the micro releases a bit more visible...

I may be wrong, but I think the concept of dual, stable and experimental, tracks, already familiar and accepted from other pieces of software, would facilitate prospective user's perception of "stable but actively supported software".

Alex