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

Ron Adam rrr at ronadam.com
Tue Jan 16 10:33:32 EST 2007


Neil Cerutti wrote:
 > On 2007-01-16, Ron Adam <rrr at ronadam.com> wrote:
 >> I have to admit that part of why assert seems wrong to me is
 >> the meaning of the word implies something you shouldn't be able
 >> to ignore.  While warnings seem like something that can be
 >> disregarded.
 >
 > Experienced C coders expect assert to behave like that.
 >
 > The only reason (I know of) to turn off error checking is to
 > optimize. However, removing tests won't usually make a big enough
 > speed difference to be worth the burthen of testing two different
 > versions of the same source code.

Ah... but that's the irony.  The whole purpose of the existence of the second
version you refer to, is to better check the first version.  These checks should
not change the flow of code that is executed!

The problem with assert as a debugging tool, is it *can* change the execution
flow by raising a catchable exception.  So you do have *two* versions that may
not behave the same.

Like I suggested earlier, assert should not be turned off *ever*, but should be
considered a nicer way to generate exceptions to do value checks.

And warnings should never change code execution order, but we should be able to
completely turn them off on the byte code level like asserts are when the -O
command line option is given.

I believe both of these features would be used a lot more if they where like this.


 > So to me the assert statement is either dubious syntax-sugar or
 > dangerous, depending on Python's command line arguments.

Yep.. unless you use them in a very limited way.


 > The warning module would seem to have limited applications.
 > Searching my Python distribution shows that it's used for
 > deprecation alerts, and elsewhere for turning those selfsame
 > alerts off. How copacetic! It is the null module. ;-)

I think you understand the point I'm trying to make.  :-)

Ron




More information about the Python-list mailing list