The Pythonic Way of Programming

Python is a concise, flexible, and versatile programming language. To keep code clean, simple, and readable, the founder of Python suggested twenty principles, which are known as the Zen of Python.

The Zen of Python

The Zen of Python is a set of golden principles or axioms for the best programming practices in Pythonic style. These guiding principles were first presented in 1999 by Tim Peters, one of Python’s founding contributors. These so-called principles became very popular among the community of Python developers and had an influence on the development process. In fact, these were eventually incorporated into the official Python Enhancement Proposal (PEP20) in 2004. Today, the Zen of Python is considered a fundamental philosophy of the language and serves as a cornerstone of best practices for Python programming. Much of these guidelines are attributed to the benevolent dictator of life (BDFL) of Python, Guido van Rossum. According to Tim Peters, these principles were his design philosophy while developing the language.

While programming, these guidelines don’t have to be strictly followed. However, these are good programming practices that define the Pythonic way of programming. These best practices are added to the Python language in the this.py module as a string object. 

How to import this

These best practices guidelines can be viewed by simply importing the this.py program. Barry Warsaw added The Zen of Python into the Python language as an Easter egg back in 2001. These 19 guiding principles can be imported using import this in the Python IDE.

The 20 golden aphorisms of Zen

These principles can be grouped into categories. However, the order might be a bit different than what is seen in this.py.

Make code readable

1. Beautiful is better than ugly. Focus on simplicity, readability, and elegance. Often, developers are not concerned about readability while coding. However, Python emphasizes well-thought-out and easy-to-use code. That’s what makes Python so popular.

2. Sparse is better than dense. Writing one-liner code that incorporates a lot of functionality might seem alluring to programmers, however, it becomes cumbersome to read. Instead of compressing the code into one line or the minimum number of lines, it’s better to keep the code sparse, spanning over multiple lines, for better readability.

3. Readability counts. The code should be easy to read. Using appropriate, easy-to-understand names for variables and functions helps. Sufficient comments in the code help any developer who wants to understand and use the code in the future. Making good use of line spacing and indentation helps improve readability.

Keep it simple

4. Simple is better than complex. If there’s a complex problem, break it down into several simpler modules and solve it. For a simple problem, obviously, keep it simple, and don't go looking around for a complex approach.

5. Complex is better than complicated. If things can’t be made simpler, don’t make things complicated. Never make things, solutions, or the code complicated.

Follow best practices

6. Flat is better than nested. Too much nesting and hierarchy make the code hard to read and understand. The code should be organized as flatly as possible.

7. Special cases aren’t special enough to break the rules. It’s best to follow the standard best practices to develop the algorithm and write the code instead of trying to create a new approach.

8. Although practicality beats purity. Well, there is no alternative to experience. If the code is readable and easy to follow, some of the principles can be deviated from to serve the purpose of practicality.

9. Namespaces are one honking great idea -- let's do more of those! Use namespaces to avoid conflicts while naming the variables. Different namespaces can coexist, but these are isolated from each other. Names in one module do not conflict with the names in another.

Handle errors

10. Explicit is better than implicit. No prior knowledge should be required for someone who wants to read a program, so keep it as explicit as possible.

11. Errors should never pass silently. If there is a silent error, the code returning None or some other error code should not let it pass silently. That might create some bugs in the future and would be hard to trace back. Instead of a program running with a silent error, it’s better if it crashes and gets fixed in time.

Remember: As the saying goes, “Seeing a spider in the room isn’t scary. It’s scary when it disappears.”

12. Unless explicitly silenced. Some errors or warnings are unavoidable, so make these silent by using the relevant commands to ignore the errors or warnings. However, it should be known where and why these errors or warnings are made silent.

13. In the face of ambiguity, refuse the temptation to guess. Always debug instead of making wild guesses. If the output does not line up with the solution, instead of making blind attempts, it’s better to understand the problem critically and reach for the right solution.

Concise

14. There should be one-- and preferably only one --obvious way to do it. If there are multiple possible solutions, choose the simplest and most obvious one, and try not to complicate things.

15. Although that way may not be obvious at first unless you're Dutch Guido van Rossumis Dutch. The obvious way might not be that obvious at first glance. However, an expert (none other than the Dutchman Guido van Rossum himself) can read things between the lines because he knows Python inside out.

Clean code

16. Now is better than never. Follow the power of now. A program should not get into an infinite execution.

17. Although never is often better than right now. At times, it is better to wait rather than quickly jump to conclusions. It’s better to wait for the program execution rather than to terminate it early.

Easy to explain

18. If the implementation is hard to explain, it’s a bad idea. Can it be explained to Joe at the coffee shop? If a developer reads the code in the future, they should easily understand it. If someone can’t understand it, that means some of the principles above were not followed.

19. If the implementation is easy to explain, it may be a good idea. If other developers can easily get the work, the work is on the right track. The solution might not be optimal or correct, but at least it follows simplicity and readability principles.

The 20th principle

Initially, 20 principles were planned. Are you wondering where the 20th principle is? It has been left for Guido to fill in, which, unfortunately, he hasn’t done so far.