assert versus print [was Re: The curious behavior of integer objects]

Steven D'Aprano steve at REMOVEME.cybersource.com.au
Mon Jan 15 22:11:03 EST 2007


On Mon, 15 Jan 2007 21:38:42 -0500, Calvin Spealman wrote:

> On 1/15/07, Steven D'Aprano <steve at removeme.cybersource.com.au> wrote:
>> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
>>
>> > assert foo(0x10) == 0  # Assertions are much better tests than prints :-)
>>
>> I dispute that assertion (pun intended).
> 
> Hah!
> 
>> Firstly, print statements work even if you pass the -O (optimize) flag
>> to Python. Your asserts don't.
> 
> This is true, but the concept can be adapted to a things like an
> assert_() function.

Hence defeating the optimization :)

So what you're saying is, some custom function that you write yourself is
better than print? I suppose I can't argue with that :)


>> Secondly, a bare assertion like that gives you very little information:
>> it just tells you that it failed:
>>
>> >>> x = 1
>> >>> assert x == 0
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>> AssertionError
>>
>> To provide the same information that print provides, you need something
>> like this:
>>
>> assert x == 0, "x == %s not 0" % x
> 
> What information would I need to know if my test passed? Nothing, I say.

Maybe. But then it is hard to tell the difference between "my test
function printed nothing because it is broken, and my test function
printed nothing because it succeeded".

There are good arguments both for and against successful tests printing a
result. Keep in mind that a successful assert doesn't actually print
"nothing" in the interactive interpreter: when it completes, you do get
feedback because Python prints a prompt. Getting feedback that the test
completed successfully is vital. The only question is whether that
feedback should be minimal or verbose.

But in any case, you have misunderstood the assertion. The error message
is printed *if the assert fails*, not if it passes.


> I only want to know when the tests fail, especially as I add more of
> them. Having no output is a great way to know nothing puked.

Sure -- for unit testing. For interactive exploration, seeing the value of
a variable is better than guessing. That's why a bare object reference in
the interactive interpreter prints itself, but in a script does nothing.



-- 
Steven D'Aprano 




More information about the Python-list mailing list