Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Anything equivalent to cassert in C++?

2 views
Skip to first unread message

Peng Yu

unread,
Nov 17, 2009, 4:19:56 PM11/17/09
to pytho...@python.org
There are some assertion code (testing if a condition is false, if it
is false, raise an Error object) in my python, which is useful when I
test my package. But such case would never occur when in the produce
code. If I keep them in if statement, it will take some runtime. I'm
wondering what is the practice that take care of the assertion code in
python.

Simon Forman

unread,
Nov 17, 2009, 5:01:38 PM11/17/09
to Peng Yu, pytho...@python.org

Read the manual:

http://docs.python.org/reference/simple_stmts.html#the-assert-statement

"In the current implementation, the built-in variable __debug__ is
True under normal circumstances, False when optimization is requested
(command line option -O). The current code generator emits no code for
an assert statement when optimization is requested at compile time."

HTH,
~Simon

Aahz

unread,
Nov 26, 2009, 12:43:13 PM11/26/09
to
In article <mailman.580.1258492...@python.org>,

You should be very careful not to put unit tests in asserts because that
prevents you from testing your application under optimization.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.

Jean-Michel Pichavant

unread,
Nov 26, 2009, 1:08:41 PM11/26/09
to Peng Yu, pytho...@python.org
Peng Yu wrote:
> There are some assertion code (testing if a condition is false, if it
> is false, raise an Error object) in my python, which is useful when I
> test my package. But such case would never occur when in the produce
> code. If I keep them in if statement, it will take some runtime. I'm
> wondering what is the practice that take care of the assertion code in
> python.
>
Would never occur ? You can't use 'would' and 'never' in the same
sentence. That is the kind of concect that make (to me) asserts diffcult
to use.
I personally never use asserts in python, cause I will end up handling
with asserts what I should in fact handle properly in what you call the
production code.

Anyway that does not answer your question I'm sorry to be off topic,
'tis just a thought. Simon gave you the proper answer.

Jean-Michel

Lie Ryan

unread,
Nov 26, 2009, 1:18:25 PM11/26/09
to

Actually, if an assert statement is never raised in production code
irrespective of the condition (even in case of malicious inputs), it is
the correct use of assert statement. The difficulty is in proving that
it is impossible to raise the assert. In most cases it is impossible to
prove and we just turn off assert when we're quite confident that it is
bug-free enough.

Grant Edwards

unread,
Nov 26, 2009, 1:58:12 PM11/26/09
to
On 2009-11-26, Jean-Michel Pichavant <jeanm...@sequans.com> wrote:
> Peng Yu wrote:
>> There are some assertion code (testing if a condition is false, if it
>> is false, raise an Error object) in my python, which is useful when I
>> test my package. But such case would never occur when in the produce
>> code. If I keep them in if statement, it will take some runtime. I'm
>> wondering what is the practice that take care of the assertion code in
>> python.
>
> Would never occur? You can't use 'would' and 'never' in the
>same sentence.

Why not? "Would never" is a very common English phrase, and
the OP used it correctly.

MRAB

unread,
Nov 26, 2009, 3:49:17 PM11/26/09
to pytho...@python.org
As in "I would never tell a francophone how to speak French". :-)

Bruno Desthuilliers

unread,
Nov 27, 2009, 4:41:48 AM11/27/09
to
Jean-Michel Pichavant a �crit :
(snip)

> I personally never use asserts in python, cause I will end up handling
> with asserts what I should in fact handle properly in what you call the
> production code.

Not the same concern. Assertions are here for 1/ documention of expected
state / value / pre|post conditions etc, and 2/ automatic verification
of these expectations *during development* - so you can immediatly spot
and fix failed expectations. IOW, it's about the "this should not, no
way, never possibly happen" cases, not the "this may eventually happen"
ones - which indeed require "proper" handling at the level you expect them.


Jonathan Hartley

unread,
Nov 27, 2009, 9:15:28 AM11/27/09
to
On Nov 26, 6:08 pm, Jean-Michel Pichavant <jeanmic...@sequans.com>
wrote:


I can see this issue has several facets to it, so I don't intend to
flagratly contradict your experience Jean-Michel, but I think that in
at least some circumstances asserts used in this way can be valuable.

One of the interesting points to come out of the recent flurry of
empirical studies of software engineering is that quality of code as
measured by defect density shows a definite negative correllation with
use of asserts in production code. (Although the significance of this
is somewhat lessened by the fact that both use of asserts and low
defect density are correlated with the level of developer experience.)

Original Microsoft paper here:
http://research.microsoft.com/apps/pubs/default.aspx?id=70290
Summary article discussing that paper and others:
http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx


Personally, I'm curious as to whether the benefit from asserts used in
this way is in helping the developer to clarify in their own mind
exactly what their expectations and invariants are.

0 new messages