[Python-Dev] Re: Stability and change
Mon, 8 Apr 2002 20:37:29 +0200
On Monday 08 April 2002 20:18, Guido van Rossum wrote:
> > You know PythonLabs's missions and goals better than I do. If such
> > goals weigh "making a new and better Python" far more highly than
> > helping spread and preserve the use of Python, then you may well be
> > right that the extra effort for (e.g.) making email part of the
> > standard distribution vs the current "maintaining a separate distro"
> > would be a bad allocation of scarce resources.
> Actually, in the minds of the people who pay my salary, "making a new
> and better Python" is one of the best ways to "help spread and
> preserve the use of Python".
Surely having a better Python (by definition of 'better') is in the long
run important. I'm not sure of how that importance compares with
perceived stability in determining how widespread Python becomes.
Judging by languages such as C or C++, stability seems paramount;
yet Java churned a lot and still managed to spread a lot too (not
without a lot of help from high-$$$ marketing efforts, though).
> > Something requiring much effort is not necessarily "obviously out":
> > it depends on how important you judge the results of those effort
> > versus the results you could have by spending the effort elsewhere.
> I very muich doubt that the corporate users who are currently worried
> about the fast pace of change are interested in any particular
> feature, and I don't think that any backported feature is going to
> make that previous version more popular amongst managers with decision
> power. The question in front of them is, "should we use Python or
> not", not "should we use Python 2.1". To answer that question, they
> want to perceive "Python" as stable, not "Python 2.1".
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. 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. 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...