Do you QA your Python? Was: 2.1 vs. 2.2

[Tim Peters]

[phil hunt]
> It is not new features that are the problem, it is new features that
> break existing code.

According to some people.  Other people have said new features are a problem
even when they're 100% backward compatible.

> IMO until Python developers adopt a policy of being very reluctant
> to do this,

Guido is very reluctant to break code, but it's not an absolute for him:
among other things, it competes with the desire to fix design mistakes in
the language, which is unusual for a language designer (not to realize that
some ideas were mistakes, but to have enough guts to repair them).  Guido is
also much more sympathetic to not breaking code that was in fact forbidden
by the docs than any C or C++ vendor would be.  The __future__ + warning
mechanism also gives explicit and controllable warnings about incompatible
changes for at least one release cycle before they happen.  Heck, I've spent
more time writing replies in this thread today than I spent adjusting to
Python changes in my own code since Python 0.9.6 was released.

> many IT managers will be wary of using it in anything other than toy
> projects,

Good for them <wink>.  Perhaps their nimbler colleagues will leave them in
the dust; perhaps not.

> and Python's user base will not grow as quickly as (IMO) it should.

We have no way to measure it.

> ...
>    New features => good
>
>    New features that break existing code => bad

New features => many new expenses and forward-compatibility headaches

Repairing flawed semantics => lower costs over time, breakage or not

are also valid points.  Good versus Evil only exists on Usenet <0.1 wink>.