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

[Steve Holden]

"phil hunt" <philh at comuno.freeserve.co.uk> wrote ...
> On Sun, 14 Apr 2002 01:02:17 -0400, Tim Peters <tim.one at comcast.net>
wrote:
> >> ...
[ talk on leaving things out left out :-)]
>
> It is not new features that are the problem, it is new features that
> break existing code.
>
And these would be ... ?

> IMO until Python developers adopt a policy of being very reluctant
> to do this, many IT managers will be wary of using it in anything
> other thsan toy projects, and Python's user base will not grow as
> quickly as (IMO) it should.
>
And your evidence that they have not yet adopted such a policy is ... ?

> >  Quite the
> >contrary, business wants bug fixes for older releases, and they *also*
want
> >new features in old releases, especially in the libraries (like, e.g.,
SSL
> >support for Windows, and support for hot new protocols
>
> Indeed. And the best way to make sure that Python gets support for
> new protocols is to make sure the user base is big enough that
> someone is bound to write an open-source library to support any new
> protocol. And the best way to achieve that is to ensure backwards
> compatibility.
>
Indeed. And the best way to ensure growth in the user base is to stop
broadcasting mis-perceptions of the True (sorry, 1) State of Affairs.

> In summary:
>
>    New features => good
>
>    New features that break existing code => bad
>
While this last assertion is uncontentious (though hardly surprising or
original), you have totally failed to provide any real evidence of code
breakage due to the recent changes in the language. On the other hand,
Andrew Kuchling recently reported on this list (in message
<slrnabba3h.h8h.akuchlin at crystal.mems-exchange.org>) that it took *minimal
effort* to port over 170,000 lines of Python code to 2.2.

So, I don't disagree with your final premise, but I would categorise your
posting and similar messages as the worst kind of FUD: stuff that's actually
put out by Python *supporters*! Andrew's remarks, however, are useful if for
no other reason than they are based on experience rather than supposition.
To quote him directly: "This means that from my point of view Python *has*
been managed for stability, and the job has been done reasonably well."

It's no use going around screaming "the sky is falling, the sky is falling".
What the developers need to know is, just exactly who is it falling on, and
where do they need to prop it up. If their investigations prove that the sky
isn't really falling at all, just drooping a little in the far left corner,
then a lot of time and energy has been wasted by people who could otherwise
have been adding really super new backward-compatible features to your
favorite language. You might be surprised about how much time the developers
have recently spent trying to ensure a better perception of Python's
stability.

In the absence of any indication that things are likely to change, perhaps a
more positive attitude would encourage others to take up Python rather than
shy away from it for completely spurious reasons. The people developing
Python are not idiots, and are just as familiar as we are with the damaging
impact of code breakage due to language design change.

the-sky-bluddywell-isn't-falling-ly y'rs  - steve