On Fri, 2009-07-10 at 11:57 -0500, Robert Kern wrote: > On 2009-07-10 11:50, J. Cliff Dyer wrote: > > On Fri, 2009-07-10 at 02:57 +0000, Steven D'Aprano wrote: > >> On Fri, 10 Jul 2009 03:28:04 +0100, Nobody wrote: > >> > >>> On Thu, 09 Jul 2009 04:57:15 -0300, Gabriel Genellina wrote: > >>> > >>>> Nobody says you shouldn't check your data. Only that "assert" is not > >>>> the right way to do that. > >>> "assert" is not the right way to check your *inputs*. It's a perfectly > >>> reasonable way to check data which "should" be valid, as well as a way > >>> to document what variables are supposed to contain. > >> Where are those variables coming from? > >> > >> The distinction really boils down to this: > >> > >> * asserts should never fail. If there is any chance that an assertion > >> might fail outside of test suites, then don't use assert. > >> > > > > I'm no expert, but the more I read this thread, and the more I think on > > it, the more I believe that asserts don't really need to exist outside > > of test suites. > > Actually, there is a good argument that one shouldn't use an assert statement > in > test suites: code can have bugs that only show up under -O so you want to be > able to run your test suite under -O. >
That's an interesting point. Presumably TestCase.assert_() doesn't suffer from this defect? Otherwise the entire unittest suite is essentially broken by your argument. I suppose I should have said one should only raise AssertionErrors in test suites. Practically speaking, that's what a test suite is: The place where you assert what the code does. -- http://mail.python.org/mailman/listinfo/python-list