[Python-Dev] Re: Stability and change

[Alex Martelli]

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