Python Assertions : The Remedy To Pre-Runtime Error Catching — Part One

Show me a bug-free software and I will show you a mother of four who still happens to be a virgin. In practice, all software has some bugs and I would rather have my team optimize for less frequent and less severe bugs rather than aiming for absolute perfection.

In software development, the sooner you uncover a bug, the better it is for everyone. Yes, if you identify a bug before it slips into production you don’t only save yourself a midnight call from that notorious client but you also take away silent-insults from your fellow brothers from the software engineering fraternity. Seriously, insults from the beer-stinking breath of some engineers (who usually can’t remember the last time they took a shower) hurts like accidentally stepping on a sharp nail.

Good error logging, internal self-checks, and wide test coverage aids in shifting the numbers in your favor when it comes to minimizing the time it takes to uncover the root cause of a bug from the instance in time when it is identified.

Every seasoned software developer will agree with me that the choice of programming languages (aka, technology stack) used to complete a particular project boils down to making a choice between speed of development (aka, programmer productivity) and speed of execution (aka, runtime performance). Languages like Ruby and Python are optimized for programmer productivity at the expense of a noticeable/unnoticeable (it depends on what you’re doing) reduction in runtime performance. Conversely, languages like C, C++ are optimized for runtime performance but hey, there’s no free launch. Yes, it takes years of practical experience and mastery to churn out quality software packages with such low-level languages which are optimized for performance (aka, speaking to the bare metals).

By the way, golang from the great minds at Google has brought everyone a language that’s as expressive as Ruby/Python and yet as performant as C/C++. Hence, golang places every developer at the midpoint between the extreme points; programmer productivity and runtime performance.

The choice between a statically typed or dynamically typed language also comes with some pros and cons and the ability to catch errors and/or type mismatch at compile-time or before runtime draws a decision boundary between these 2 categories of languages. If you choose a statically type language (Google it, if you don’t know. Google knows everything!) the compiler does a good job at catching some types of errors hence you’re saved from shipping crap that will earn you that dreaded midnight call (it could actually land you a slap in severe cases).

If your only reason for avoiding (or even hating) dynamic languages (again, Google it, if you don’t know) is the lack for compile-time error checking then I’ll humbly suggest that you pick a good book on that language or dive deep into the language’s documentation. I bet you, there’s always provisions made for disciplined programmers to check and stop certain bugs from getting shipped. Dynamically typed languages bring great freedom but as my grandfather(yes, my grandfather is the original source of this quote. Using it without appropriate reference is prohibited by law; my law!) said “With great freedom comes great responsibility”. So, mathematically speaking (with tools of induction from logical reasoning) I can conclude that irresponsible people choose statically typed languages. But, before you hit me in the face for the above statement, check page 132 of your Discrete Mathematics book (yeah, induction is always taught on page 132). Just kidding bro, take it easy.

Python (one of my favorite languages) is optimized for programmer productivity, packed with immense freedom because it is dynamically typed and very expressive, but doesn’t lack the ability to prevent subtle errors from slipping into the hands of users.

In a series of posts on this subject matter, I seek to demystify any myths surrounding the use of assertions in python. You’ll be empowered to fearlessly push your code to production without testing. (Don’t call me when you’re fired for this though, lol).

As always, thanks for reading and check soon for other stories in this series.