This article is on stackoverflow's Questions and Answers about The Zen of Python (CC BY-SA3.0 License). The Japanese translation of The Zen of Python was based on "What are we looking for in" Python "?". ..
The Zen of Python is a concise summary of the attitudes Python programmers should have. This should be of great help to programmers who don't write Python. By the way, "Zen" is Japanese "Zen".
You don't have to try to read the full text from the beginning. We encourage you to take a quick look at this article and read the parts that interest you.
The full text is on the Python interpreter
>>> import this
You can display it by typing.
The full text is below.
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Beautiful is better than ugly.
Explicit is better than implicit.
It is better to clarify than to imply.
Simple is better than complex.
It's better to be plain than complicated.
Complex is better than complicated.
Still, it's better to be complicated than complicated.
Flat is better than nested.
The nest should be shallow.
Sparse is better than dense.
It's better to have a gap than to be crowded.
Readability counts.
Easy to read is good.
Special cases aren't special enough to break the rules.
Being special is not a reason to break the rules.
Although practicality beats purity.
However, when it comes to practicality, purity can be lost.
Errors should never pass silently.
Don't hide the error, don't ignore it.
Unless explicitly silenced.
However, if it is hidden on purpose, don't miss it.
In the face of ambiguity, refuse the temptation to guess.
If you come across something ambiguous, don't guess what it means.
There should be one-- and preferably only one --obvious way to do it.
There must be some good way. There is only one way that is obvious to everyone.
Although that way may not be obvious at first unless you're Dutch.
The method may be difficult to understand at first glance. It may be easy to understand only for Dutch people.
Now is better than never.
Do it now, rather than not doing it all the time.
Although never is often better than *right* now.
But now"soon"It's often better not to do it than to do it.
If the implementation is hard to explain, it's a bad idea.
If it's hard to explain what the code is, it's a bad implementation.
If the implementation is easy to explain, it may be a good idea.
If you can easily explain the content of the code, it's probably a good implementation.
Namespaces are one honking great idea -- let's do more of those!
Namespaces are a great idea and should be actively used.
Then, I will explain the original text line by line.
Beautiful is better than ugly. Beautiful is better than ugly.
(Respondent: J.T. Hurley)
With Python, you can find the greatest common divisor with just this much code.
def gcd(x, y):
while y:
x, y = y, x % y
return x
The more beautiful the algorithm, the more beautiful the code. And Python can express its beauty with a small number of lines.
Explicit is better than implicit. It is better to clarify than to imply.
Don't do this.
from os import *
print(getcwd())
Make it easy to see from which module the function is provided.
import os
print(os.getcwd())
The Zen of Python says:
Namespaces are one honking great idea - let's do more of those!
Namespaces are a great idea.
Therefore, in Python, when calling a method, when referencing a field, specify self even in the class. Programmers should always be aware of what and where the objects they are using are.
Some scripting languages can do this.
test.php
<?php
$foo = "5";
echo $foo * 3;
?>
When executed, it becomes like this.
$php test.php
15
This happens because the character string is regarded as an integer when the operation of character string x integer is performed. It's called implicit type conversion. But in Python I get an error like this:
>>> foo = "5"
>>> foo+3
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
If you want the result to be returned as an integer, you need to specify it.
>>> int(foo)+3
8
Simple is better than complex. It's better to be plain than complicated.
Complex is better than complicated. Still, it's better to be complicated than complicated.
Referenced page: What does “Complex is better than complicated” mean? (Respondent: EinLama)
Being complicated or esoteric is a little different from being complicated.
Let's take this code as an example.
counter = 0
while counter < 5:
print(counter)
counter += 1
This code should be very easy to understand. But this code is esoteric. Two elements, "managing counter variables" and "displaying values with print statements", are mixed up in one code.
for i in xrange(5):
print(i)
On the other hand, this code is more complex than the example using wihle. There is a clear separation between the two elements of "counter variable management" and "printing the value". If you don't know xrange, you may not know what this code is doing. But if you want to write clean code, the cost of finding out what xrange is isn't that great. You can easily understand how xrange works by reading the documentation.
The larger the code, the greater the difference in manageability between esoteric code and complex code. Of course, the simpler and easier to write, the easier it is to manage.
Beautiful is better than ugly.
Flat is better than nested.
The nest should be shallow.
### Example
(Respondent: [S.Lott](https://stackoverflow.com/users/10661/s-lott))
For example, the classes provided by Java and C ++ libraries usually inherit from other classes.
When this happens, you have to think about how the class you want to use inherits from other classes.
Therefore, it becomes difficult to properly understand and use the library specifications.
But with Python, you don't have to write __com.company.java.blah.blah__ when using standard modules. Most of the time it should be __timeit__ or __csv__. This is possible because the namespace is built flat.
Sparse is better than dense.
It's better to have a gap than to be crowded.
### Example
```python
if i>0: return sqrt(i)
elif i==0: return 0
else: return 1j * sqrt(-i)
if i > 0:
return sqrt(i)
elif i == 0:
return 0
else:
return 1j * sqrt(-i)
Which is easier to read, the code above or the code below?
Don't try to pack too much into one line.
Readability counts. Easy to read is good.
(Respondent: Federico A. Ramponi)
Let's compare C and Python.
#include <stdio.h>
int main(void) {
printf("Hello, world!\n");
return(0);
}
print("Hello, world!")
Even with the same "Hello, World!", The readability is completely different between C and Python. With Python, you can see at a glance what your code is doing.
Special cases aren't special enough to break the rules. Being special is not a reason to break the rules.
Although practicality beats purity. However, when it comes to practicality, purity can be lost.
(Respondent: Federico A. Ramponi)
Python doesn't have a "character-only" type like char. It's not as special as it needs a special mold. However, in pursuit of practicality, a function that takes or returns a character of length 1 such as chr or ord is required.
Errors should never pass silently. Don't hide the error, don't ignore it.
(Respondent: Ali Afshar)
For example, don't write this code.
try:
import this
except ImportError:
pass
Make it clear that an error has been detected.
try:
import this
except ImportError:
print('this is not available')
Unless explicitly silenced. However, if it is hidden on purpose, don't miss it.
(Respondent: Ali Afshar)
Let's take a look at this code.
d = dict((('spam', 1), ('ham', 2)))
default = 0
k = 'eggs'
try:
v = d[k]
except KeyError:
v = d[k] = default
print("v:{}".format(v))
print("d:{}".format(d))
When executed, it becomes like this.
$python silenced.py
v:0
d:{'eggs': 0, 'ham': 2, 'spam': 1}
This code sets the key to a default value when it doesn't exist. The except clause does not notify the outside that an error has occurred. Because I do that on purpose.
In the face of ambiguity, refuse the temptation to guess. If you come across something ambiguous, don't guess what it means.
When will this conditional statement be true?
if not a and b:
pass
Rewrite it like this
if b and not a:
pass
Or it's a little clunky, but it's better to write:
if (not a) and b:
pass
There should be one-- and preferably only one --obvious way to do it. There must be some good way. There is only one way that is obvious to everyone.
(Respondent: Federico A. Ramponi)
There are various ways to look at the elements of an array in order in C ++, depending on the type. (I'm not familiar with C ++ so please let me know if you have a good example)
But with Python, that's all you need. It doesn't matter if the target is a dictionary or a list, everything is fine in this way.
for element in sequence:
Although that way may not be obvious at first unless you're Dutch. The method may be difficult to understand at first glance. It may be easy to understand only for Dutch people.
"Dutch" here refers to Python developer Guido van Rossum. See here for more information. I want it.
(Respondent: S.Lott)
There was a heated debate about the if-then-else clause (cond? Expr1: expr2 in C). In it Guido proposed this.
a = expr1 if cond else expr2
This is the only way to write an if-then-else clause in Python. However, it is difficult to understand at first glance.
Now is better than never Do it now, rather than not doing it all the time.
(Respondent: wim)
never
f = open('stay_open.txt', 'w')
f.write('every even number > 2 is the sum of two primes')
raise AssertionError('this sentence is false')
f.close()
now
with open('will_be_closed.txt', 'w') as f:
f.write('the sum of two primes > 2 is an even number')
raise AssertionError('this sentence is false')
Did you notice what's wrong with the never code? The never code will assert the connection to the file without closing it. The idea of "because I'll close it later" gives rise to bad code. However, the now code will close the connection to the file properly even if an error occurs.
The never code can also be rewritten as:
try:
f = open('will_be_closed.txt', 'w')
f.write('every even number > 2 is the sum of two primes')
assert not 'this sentence is false'
finally:
f.close()
But beautiful is better than ugly.
Beautiful is better than ugly.
Although never is often better than right now. But it's often better not to do it now than to do it "immediately".
Over-optimizing your code early on can often be a waste of time.
For example, if you need to implement sorting, you often don't need to implement quicksort from scratch. Quicksort is generally more difficult to implement than bubble sort. In reality, bubble sort is a sufficient problem, but writing with quick sort from the beginning is a waste of time. At the test stage, use bubble sort for the time being, and rewrite it to quicksort when necessary.
If the implementation is hard to explain, it's a bad idea. If it's hard to explain what the code is, it's a bad implementation.
If the implementation is easy to explain, it may be a good idea. If you can easily explain the content of the code, it's probably a good implementation.
Namespaces are one honking great idea -- let's do more of those! Namespaces are a great idea and should be actively used.
(Respondent: Federico A. Ramponi, Editor: wim)
When using the module, write like this.
import module
module.spam()
import module
breakfast = module.SpamAndEggs()
Don't write this.
from module import *
You can write this only when testing a function in a terminal. If you write this in a normal program, the names may conflict. Also, readability is reduced because you do not know which module the function belongs to.
If the module name or class name is long, you can use as.
import aRidiculouslyLongModuleName as short
If you have any questions or concerns, please comment.
The Zen of Python What are we looking for in "Python"? What does “Complex is better than complicated” mean? An Introduction to the Zen of Python
Recommended Posts