Clarity vs. code reuse/generality

[Robert Kern]

On 2009-07-10 13:56, J. Cliff Dyer wrote:
> 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.

It explicitly raises AssertionErrors. It does not use the assert statement.

> 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.

Yup.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco