The Zen of Python is more than just guidance on designing this programming language. As an aspiring developer, you won’t just learn why Python is designed but can also pick up some good advice on writing code.
The Zen of Python
The Zen of Python is a set of rules about writing software by Tim Peters, a celebrated software engineer who participated in this language’s early development. He had major contributions to and had a great influence on how Python was designed in its first years.
During a conversation in Python’s mailing list in 1999, Tim Peters proposed 19 principles he thought Python should be based on. He actually left the 20th rule for Guido van Rossum (the creator of Python) to fill in. But Van Rossum never added the final one and the Zen of Python still consists of 19 principles, all written by Peters.
They have been included in Python as the Python Enhancement Proposal 20 (PEP20) and released to the public domain.
You can view these rules in the official interpreter as an Easter egg by entering import this:
These principles reflect the core philosophy of the Python programming language. Many programmers also see them as the best practices – the way Python programs should be written.
You might agree with them or not, but a good understanding of these rules is helpful nonetheless. They can be applied to make your code more readable, elegant, easier to maintain and prevent some common problems.
Explain The Zen of Python’s Guidelines
Beautiful is better than ugly.
When the deadline gets nearer, developers tend to churn out messy code quickly without giving its readability much thought. But your code should always be consistent and easy to work with.
Explicit is better than implicit.
Assume that you are writing for someone who doesn’t know much about your program and its purpose. Make your code explicit, verbose, and easy to understand without prior knowledge. Refrain from using obscure features or hidden functionality.
Simple is better than complex. Complex is better than complicated.
There is always more than one way to solve a problem. It is your decision whether to go with a quick but complicated approach. Break down your problem into smaller ones and prefer simpler techniques when possible.
Flat is better than nested.
Sometimes hierarchical structure does more harm than good. Try to minimize nesting to make your code less confusing and improve its readability.
Sparse is better than dense.
z = lambda x: [[y for b, y in enumerate(set(x)) if (a >> b) & 1] for a in range(2**len(set(x)))]
Don’t try to compress too much functionality into a single line of code like this:
One-liners may look impressive, but others, and even your future self, will get infuriated trying to understand them later.
Readability counts.
Always follow the best practices to make your code as readable as possible. Keep in mind that while you may have only to write your code only once, it may be read several times.
For instance, the second variable name here will make your program less ambiguous:
>>> a = ['learnshareit', 'quora', 'reddit'] >>> qa_sites = ['learnshareit', 'quora', 'reddit']
Special cases aren’t special enough to break the rules. Although practicality beats purity.
Try to stick to the best practice first before going your own way with a new problem. Still, there are times when you can break the rule to make more readable and practical code.
Errors should never pass silently. Unless explicitly silenced.
It is better to raise errors and crash than silencing them and continuing with your program, or it would be harder to debug the code later on. However, always give the option of explicitly ignoring the errors as long as you know what you are doing.
In the face of ambiguity, refuse the temptation to guess.
When facing a problem, don’t throw everything at the wall to see what sticks. That is a poor strategy that will consume much time and effort. Use more critical thinking and less guessing to investigate your issue and come up with a solution.
There should be one– and preferably only one –obvious way to do it.
Multiple solutions for a problem can give you more flexibility, but they are also a double-edged sword. You will need to spend more effort understanding these solutions thoroughly enough to make the best choice.
Although that way may not be obvious at first unless you’re Dutch.
This is a joke aimed at Guido van Rossum, who is Dutch. After all, its creator can understand Python and its rules much better than any of us.
Now is better than never. Although never is often better than *right* now.
A program that needs more time to finish is better than one that stops early with wrong results. Optimization isn’t worth it when you can’t achieve the ultimate goals of your code.
If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea.
In Python, simplicity has a higher priority over speed. High-performance code isn’t a good idea when other people have a hard time understanding it.
Namespaces are one honking great idea — let’s do more of those!
Python namespaces allow you to put names in different scopes. Make use of them to prevent conflicts when duplicate names happen.
Summary
With the Zen of Python, Tim Peters summed up his most essential principles when writing software, especially in Python. They aren’t always true, but you should always keep these rules in mind when working with Python.
Maybe you are interested:
- Get the memory usage of an Object in Python
- Online Python Compiler: Write And Run Code In Your Browser
- Check package versions in python
Hi guys, wellcome to LearnShareIt. I’m Tiffany and I’m also who responsible for the quality of this website’s content. I previously worked on software development projects for ten years as a developer. Hopefully, our project will bring a lot of value to the community.
Job: Programmer/Project management
Major: IT
Programming Languages: Python, C, HTML, MySQL, SQL Server, C#, C++, Javascript, CSS, Java, VB
