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

Alex Martelli aleax@aleax.it
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...

Alex