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

[Hans-Joachim Widmaier]

Tim Peters <tim.one at comcast.net> wrote in message news:<mailman.1018825230.16052.python-list at python.org>...

> 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.

I think nobody likes code breaking in new releases, as well as noone
wants to introduce them. So far the incompatibilities weren't all that
great--properly written code usually ran without a hitch on new
releases. And the things that didn't were usually quite easy to spot
(threw exceptions) or gave warnings. One thing that I like about
python (apart from all the well-known things) is that the designers
actually try to fix design flaws. Even if it means some work for me,
I'd rather have it fixed *now* than wait another 2 years, when it'll
be next to impossible due to an even greater code base that yells
"don't change!" And yes, complaining about something often takes more
time than fixing it right away.

Back-to-lurking'ly,
Hans-J.