On 6/1/07, Fred L. Drake, Jr. <fdrake@acm.org> wrote:
Changes in general are a source of risk; they have to be considered carefully. We've seen too many cases in which a change was thought to be safe, but broke something for someone. Avoiding style-only changes helps avoid introducing problems without being able to predict them; there are tests for ConfigParser, but it's hard to be sure every corner case has been covered.
I understand what you mean, all changes carry a certain risk. Especially in code that is so widely relied upon as the Standard Library. But the alternative, which is to let the code rot, while one-line fixes are applied upon it, is a much worse alternative. It is true that unit tests does not cover all corner cases and that you can't be 100% sure that a change won't break something for someone. But on the other hand, the whole point with unit tests is to facilitate exactly these kind of changes. If something breaks then that is a great opportunity to introduce more tests.
This is a general policy in the Python project, not simply my preference. I'd love to be able to say "yes, the code is painful to read, let's make it nicer", but it's hard to say that without being able to say "I'm sure it won't break anything for anybody." Python's too flexible for that to be easy.
While what you have stated is the policy, I can't help but think that it is totally misguided (no offense intended). Maybe the policy can be reevaluated? -- mvh Björn