Smash Company Splash Image

November 2nd, 2014

In Technology

1 Comment

Why not use asserts in Python?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:

I use asserts a great deal in Clojure. They partly take the place of unit tests. Apparently they are mostly unused in the world of Python, although some of the reasons listed here would be general to any language:

Several reasons come to mind…

It is not a primary function

Many programmers, lets not get bogged down by the rationale, disrespect anything which is not a direct participant in the program’s penultimate functionality. The assert statement is intended for debugging and testing, and so, a luxury they can ill-afford.

Unit Testing

The assert statement predates the rise and rise of unit-testing. Whilst the assert statement still has its uses, unit-testing is now widely used for constructing a hostile environment with which to bash the crap out of a subroutine and its system. Under these conditions assert statements start to feel like knives in a gunfight.

Improved industry respect for testing

The assert statement serves best as the last line of defence. It rose to lofty and untouchable heights under the C language, when that language ruled the world, as a great way to implement the new-fangled “defensive programming”; it recognises and traps catastrophic disasters in the moment they teeter on the brink. This was before the value of Testing became widely recognised and respected and disasters were substantially more common.

Today, it is unheard of, for any serious commercial software to be released without some form of testing. Testing is taken seriously and has evolved into a massive field. There are Testing professionals and Quality Assurance departments with big checklists and formal sign-offs. Under these conditions programmers tend not to bother with asserts because they have confidence that their code will be subjected to so much tiresome testing that the odds of wacky brink-of-disaster conditions are so remote as to be negligible. That’s not to say they’re right, but if the blame for lazy programming can be shifted to the QA department, hell why not?

These reasons are more specific to Python, but it is curious why the “optimized mode” is not used more commonly:

I guess the main reason for assert not being used more often is that nobody uses Python’s “optimized” mode.

Asserts are a great tool to detect programming mistakes, to guard yourself from unexpected situations, but all this error checking comes with a cost. In compiled languages such as C/C++, this does not really matter, since asserts are only enabled in debug mode.

In Python, on the other hand, there is no strict distinction between debug and release mode. The interpreter features an “optimization flag” (-O), but currently this does not actually optimize the byte code, but only removes asserts.

Therefore, most Python users just ignore the -O flag and run their scripts in “normal mode”, which is kind of the debug mode since asserts are enabled and __debug__ is True, but is considered “production ready”.

Maybe it would be wiser to switch the logic, i.e., “optimize” by default and only enable asserts in an explicit debug mode, but I guess this would confuse a lot of users and I doubt we will ever see such a change.

There is PEP which focuses on contract programming in Python:

This submission describes programming by contract for Python. Eiffel’s Design By Contract(tm) is perhaps the most popular use of programming contracts [2].

Programming contracts extends the language to include invariant expressions for classes and modules, and pre- and post-condition expressions for functions and methods.

These expressions (contracts) are similar to assertions: they must be true or the program is stopped, and run-time checking of the contracts is typically only enabled while debugging. Contracts are higher-level than straight assertions and are typically included in documentation.


Python already has assertions, why add extra stuff to the language to support something like contracts? The two best reasons are 1) better, more accurate documentation, and 2) easier testing.

Complex modules and classes never seem to be documented quite right. The documentation provided may be enough to convince a programmer to use a particular module or class over another, but the programmer almost always has to read the source code when the real debugging starts.

Contracts extend the excellent example provided by the doctest module [4]. Documentation is readable by programmers, yet has executable tests embedded in it.

Testing code with contracts is easier too. Comprehensive contracts are equivalent to unit tests [8]. Tests exercise the full range of pre-conditions, and fail if the post-conditions are triggered. Theoretically, a correctly specified function can be tested completely randomly.

So why add this to the language? Why not have several different implementations, or let programmers implement their own assertions? The answer is the behavior of contracts under inheritance.

Suppose Alice and Bob use different assertions packages. If Alice produces a class library protected by assertions, Bob cannot derive classes from Alice’s library and expect proper checking of post-conditions and invariants. If they both use the same assertions package, then Bob can override Alice’s methods yet still test against Alice’s contract assertions. The natural place to find this assertions system is in the language’s run-time library.

This is an insightful phrase: “behavior of contracts under inheritance”. There is some cost to being a multi-paradigm language, and it shows in a situation like this, where 2 desirable goals are in conflict with each other. Ordinarily, faced with the need for a new control structure, Lisp programmers would say “That is what macros are for.” And, indeed, in a Lisp such as Clojure, there are multiple packages for enforcing contracts, and you can use the packages together without much worry of conflicts. But Clojure does not have to worry about inheritance. It really is the combination of “contracts under inheritance” that creates the need for this functionality to be in the core of the language.

I notice that PEP was introduced in 2003 and has gone nowhere since. I guess this idea is not popular in the Python community? I wonder why.


Check out my book:


April 14, 2019 4:34 pm

From lawrence on Abuse on Wikipedia

"Just An Observer, please post the link if you find it...."

April 14, 2019 12:28 pm

From Just An Observer on Abuse on Wikipedia

"Well, wouldn't you know, the slagging of Katy Bouman who is the algorithm designer for the black hole image is..."

April 11, 2019 4:30 pm

From Just An Observer on Abuse on Wikipedia

"In a similar vein, yesterday a woman scientist wrote about how Wikipedia articles about woman scientists are o..."

March 30, 2019 5:31 pm

From lawrence on Don't waste your life on Twitter

"Orbay, with any type of creative endeavor, I think you'll find 90% of the output is mediocre. That is true for..."

March 30, 2019 4:51 am

From Orbay on Don't waste your life on Twitter

"I agree, but you consider a great game a great achievement, not money from wasting other people's lives? I..."

March 21, 2019 10:38 pm

From Adam Trepanier on Object Oriented Programming is an expensive disaster which must end

"Thank you for this post. This sums up what I have been feeling for years now with OOP in such a great way. I..."

March 13, 2019 1:58 pm

From ball on Facebook activated my dormant account and it won't let me deactivate it

"Same shit here. I regret ever making a spraybook account..."

February 20, 2019 10:41 am

From Just An Observer on Don't waste your life on Twitter

"A couple of my favorite bloggers started doing twitter. Instead of permanent additions to knowledge, there is..."

February 20, 2019 3:24 am

From Brennan on Did sleep paralysis start the Salem Witch Trials?

"If you have occasional sleep paralysis, you can take steps at home to control this disorder. Start by making s..."

February 19, 2019 11:09 am

From Ryan Earp on Why I prefer dynamic-typing over static-typing: the speed of adapting to change

"If static typing lead to greater programmer productivity (via a reduction in bugs) then corporate Americ..."

February 3, 2019 2:32 pm

From ruurd on Argument about attraction and sexuality and trans

"wait wait wut? what's the liberals doing here?..."

January 18, 2019 10:22 am

From Justin McGuire on When will the era of CyberPunk end?

"The reason cyberpunk doesn't die is because it all came true. From Noah Smith on twitter: "The cool thing a..."

December 16, 2018 9:06 am

From lawrence on Yair Lapid: What does it say about us that Israel has become the only democracy in the world in which Jews don’t have freedom of religion?

"Cat Mara, thank you for catching that. I've fixed it now. (The URL was a "v" by mistake. Looks like I was tryi..."

December 12, 2018 7:50 pm

From lawrence on Object Oriented Programming is an expensive disaster which must end

"Jussi Nurminen, thank you for writing. I believe you are correct, in the sense that Python 2.x had all the bas..."


November 7, 2018
6:04 pm

By Henry Longmore

Thanks for the article. I used to mock Eiffel for its “Design By Contract” as that seemed to be the only good reason to program in Eiffel. I was unaware of the PEP to add contracts to python. Another nice benefit of doing so as described in the PEP is that the tests (by way of invariants and contracts) are near the code being tested, which seems like it would make writing tests easier.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>