That's all fine and good but in this case there may be "stealth errors". If the user/programmer is expecting the first value to hold but instead

On Fri, Jun 27, 2008 at 7:03 PM, Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 27, 2008 at 2:54 PM, Fred Drake <fdrake@acm.org> wrote:
> On Jun 27, 2008, at 5:23 PM, Benjamin Peterson wrote:
>>
>> I think code that uses this is probably already quite broken in some
>> fundamental way and putting the fix in 2.5 isn't much of a risk.
>
> I suspect the risk has more to do with breaking something else in Python
> than in breaking 3rd-party code in this case.
>
> I think it should be fixed for 2.5 as well, myself.

Let me clarify why I want to be so careful with this.

If there is code that was expected to work but due to a bug in our
code raises an exception, it's generally safe to fix this: people who
ran into the issue found that their code didn't work, used a
work-around, and that's the end of the story.

But if there is code that was expected to *break* but due to a bug in
our code *doesn't* raise an exception, people can very well have
harmless occurrences of such code, and never noticed. Maybe their code
is "broken" in the sense that it doesn't produce the correct result,
but it may well be in a "don't care" way -- but if an upgrade suddenly
starts raising the exception, they are likely to get unhandled
exceptions where before they had none. This is particularly annoying
when the author of the program that breaks is not the user of the
program, to whose machine the upgrade was applied.

In such cases I think it's better not to introduce new exceptions in
point-point releases.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________



--
Haikus are easy
Most make very little sense
Refrigerator