2.1 PEP 20 – The Zen of Python

The Zen of Python is a collection of 19 aphorisms, which reflect the philosophy behind Python, its guiding principles, and design.

Tim Peters, a long time major contributor to the Python programming language and Python community, wrote this 19-line poem on the Python mailing list in 1999, and it became entry #20 in the Python Enhancement Proposals in 2004.

It’s one of the Easter eggs (i.e., hidden, secret messages or features) included in the Python interpreter.

Now let’s see the magic. Go to the editor window, type in import this, run the code, and voilà! Can you see what happens?

What you see is a collection of some general truths for Python design rules and decision making. Even though the «poem» seems to be imbued with contradictions and allusions, we assure you that the aphorisms are extremely practical and common sense, and you’re encouraged to accept them and implement in your code.

These, of course, should be looked upon holistically, rather than individually, but, still, let’s try to meditate on each of them.

Beauty is a rather subjective experience. But, as Immanuel Kant said, the very esthetic experience of beauty is a judgement of human truth.

And even though the computer doesn’t care about beauty or esthetics, people do, and we must remember that a nicely-written program is not only more enjoyable to read, but also more readable.

Python has certain style rules that programmers are recommended to follow. These are, among other things: a 79-character maximum line length, variable naming conventions, placing statements on separate lines, and many others.

Example: Write a program that calculates the hypotenuse of a right-angled triangle.

The code you write should be explicit and readable.

Whenever you want to use an implicit feature of the language, ask yourself whether you really need it. Maybe there’s a better way to implement the functionality. If not, think about leaving a comment in code to explain what’s going on so that other programmers find it easier to understand your code.

In Python, it’s preferred to use not only the simplest way to express a programming idea, but also the most explicit, concrete, specific one.

Therefore, it’s sometimes a good idea to add more verbosity to your code as it all counts towards readability. Giving self-explanatory variable and function names, or adding more explicitness to imports or function arguments may be good practice.

Example: Import apples and bananas from the fruit.py module.

Simplicity is the key to success.

A simpler solution is usually preferred over a complex one, and generally, the minimalistic approach wins. Remember: use appropriate tools adjusted to the specificity of your project.

Using a plane to transport yourself to a nearby shop could be okay (assuming you’re slightly eccentric), but usually it’d be enough to walk or drive. Similarly, you wouldn’t normally walk the distance if you wanted to travel from the UK to the USA. Taking a plane would be a more sensible idea here.

Consider not adopting an object-oriented approach when it’s not needed. Use fewer lines of code if that’s possible.

If you need to implement a more complex solution, divide problems into smaller, simpler parts.

Example: Sort the numbers list in ascending order.

When simple solutions are not possible, be aware of the limitations carried by simplicity, and use complex solutions instead.

Distinguishing between complex as consisting of many elements and complicated, meaning difficult to understand, is yet another thing to consider when writing code.

In other words, there are times when a complex solution may be preferred over a simple one, especially in the case of the latter causing misunderstanding, doubt, or misinterpretation. You should avoid those.

On the other hand, complex is always preferred to complicated. When your code gets big and too difficult to understand and grasp, divide it into well-separated parts, so that it’s easier to manage and handle.

Example: Perform five additions of two numbers.

Nesting code makes it more difficult to follow and understand. Nesting two or three levels deep may still be good, but anything beyond that becomes confusing and unreadable.

Even though you can actually have any level of nested loops or if statements in Python, anything above three should be a clear signal that it’s maybe a good time to start refactoring your code.

Flat code is more user-friendly, and becomes much easier to maintain. Remember this.

Example: Display a message whether or not x is within the range from 4 to 6.