Danek Duvall added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7918> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
