Making trade-offs when writing Python code | Opensource.com

Making trade-offs when writing Python code

This is part of a special series about the Zen of Python focusing on the seventh, eighth, and ninth principles: readability, special cases, and practicality.

Brick wall between two people, a developer and an operations manager
x

Subscribe now

Get the highlights in your inbox every week.

Software development is a discipline rife with trade-offs. For every choice, there is an equally defensible but opposite choice. Make a method private? You're encouraging copy-paste. Make a method public? You're committing prematurely to an interface.

Software developers make hard choices every minute. While all the principles in the Zen of Python cover trade-offs to some extent, the following principles take the hardest, coldest look at some trade-offs.

Readability counts.

In some sense, this middle principle is indeed the center of the entire Zen of Python. The Zen is not about writing efficient programs. It is not even about writing robust programs, for the most part. It is about writing programs that other people can read.

Reading code, by its nature, happens after the code has been added to the system. Often, it happens long after. Neglecting readability is the easiest choice since it does not hurt right now. Whatever the reason for adding new code—a painful bug or a highly requested feature—it does hurt. Right now.

In the face of immense pressure to throw readability to the side and just "solve the problem," the Zen of Python reminds us: readability counts. Writing the code so it can be read is a form of compassion for yourself and others.

Special cases aren't special enough to break the rules.

There is always an excuse. This bug is particularly painful; let's not worry about simplicity. This feature is particularly urgent; let's not worry about beauty. The domain rules covering this case are particularly hairy; let's not worry about nesting levels.

Once we allow special pleading, the dam wall breaks, and there are no more principles; things devolve into a Mad Max dystopia with every programmer for themselves, trying to find the best excuses.

Discipline requires commitment. It is only when things are hard, when there is a strong temptation, that a software developer is tested. There is always a valid excuse to break the rules, and that's why the rules must be kept the rules. Discipline is the art of saying no to exceptions. No amount of explanation can change that.

Although, practicality beats purity.

"If you think only of hitting, springing, striking, or touching the enemy, you will not be able actually to cut him."
— Miyamoto Musashi, The Book of Water

Ultimately, software development is a practical discipline. Its goal is to solve real problems, faced by real people. Practicality beats purity: above all else, we must solve the problem. If we think only about readability, simplicity, or beauty, we will not be able to actually solve the problem.

As Musashi suggested, the primary goal of every code change should be to solve a problem. The problem must be foremost in our minds. If we waver from it and think only of the Zen of Python, we have failed the Zen of Python. This is another one of those contradictions inherent in the Zen of Python.

Person reading a book and digital copy

This is the second part of a special series about the Zen of Python focusing on the third and fourth principles: simplicity and complexity.
Searching for code

Welcome to Pythonukkah, a special series about the Zen of Python. On the first day, we celebrate the first two principles: beauty and explicitness.
Digital creative of a browser on the internet

This is part of a special series about the Zen of Python focusing on the fifth and sixth principles: flatness and sparseness.

Topics

About the author

Moshe sitting down, head slightly to the side. His t-shirt has Guardians of the Galaxy silhoutes against a background of sound visualization bars.
Moshe Zadka - Moshe has been involved in the Linux community since 1998, helping in Linux "installation parties". He has been programming Python since 1999, and has contributed to the core Python interpreter. Moshe has been a DevOps/SRE since before those terms existed, caring deeply about software reliability, build reproducibility and other such things. He has worked in companies as small as three people and as big as tens of thousands -- usually some place around where software meets system administration...