This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dhduvall
Recipients Oliver.Jeeves, dhduvall, dstufft, eric.araujo, tarek
Date 2014-09-02.22:47:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1409698046.94.0.26489698223.issue7918@psf.upfronthosting.co.za>
In-reply-to
Content
Absolutely true that developers should have tests that would detect such bugs.  However, the sooner you detect a bug, the more time you save.  And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests).

Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain).  Wouldn't you think that was stunningly broken?

Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default.  Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed.
History
Date User Action Args
2014-09-02 22:47:27dhduvallsetrecipients: + dhduvall, tarek, eric.araujo, Oliver.Jeeves, dstufft
2014-09-02 22:47:26dhduvallsetmessageid: <1409698046.94.0.26489698223.issue7918@psf.upfronthosting.co.za>
2014-09-02 22:47:26dhduvalllinkissue7918 messages
2014-09-02 22:47:26dhduvallcreate