Cet article provient de stackoverflow Questions et réponses sur le zen de Python Ceci est une traduction de (Licence CC BY-SA3.0). La traduction japonaise de The Zen of Python était basée sur "Que recherchons-nous dans" Python "?". ..
Le Zen of Python est un résumé concis des attitudes que les programmeurs Python devraient avoir. Cela devrait être d'une grande aide pour les programmeurs qui n'écrivent pas Python. Au fait, «Zen» est «Zen» japonais.
Vous n'êtes pas obligé d'essayer de lire le texte intégral depuis le début. Nous vous recommandons de jeter un coup d'œil à cet article et de lire les parties qui vous intéressent.
Le texte complet est sur l'interpréteur Python
>>> import this
Vous pouvez l'afficher en tapant.
Le texte intégral est ci-dessous.
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Beau est mieux que laid.
Explicit is better than implicit.
Il vaut mieux clarifier que suggérer.
Simple is better than complex.
Il vaut mieux être simple que compliqué.
Complex is better than complicated.
Pourtant, il vaut mieux être compliqué que compliqué.
Flat is better than nested.
Le nid doit être peu profond.
Sparse is better than dense.
Il vaut mieux avoir un écart que d'être encombré.
Readability counts.
Facile à lire, c'est bien.
Special cases aren't special enough to break the rules.
Être spécial n'est pas une raison pour enfreindre les règles.
Although practicality beats purity.
Cependant, en ce qui concerne l'aspect pratique, la pureté peut être perdue.
Errors should never pass silently.
Ne cachez pas l'erreur, ne l'ignorez pas.
Unless explicitly silenced.
Cependant, s'il est caché exprès, ne le manquez pas.
In the face of ambiguity, refuse the temptation to guess.
Si vous rencontrez quelque chose d'ambigu, ne devinez pas ce que cela signifie.
There should be one-- and preferably only one --obvious way to do it.
Il doit y avoir un bon moyen. Il n'y a qu'une seule façon qui soit évidente pour tout le monde.
Although that way may not be obvious at first unless you're Dutch.
La méthode peut être difficile à comprendre à première vue. Seuls les Néerlandais peuvent facilement comprendre.
Now is better than never.
Faites-le maintenant, plutôt que de ne pas le faire tout le temps.
Although never is often better than *right* now.
Mais maintenant"bientôt"Il vaut souvent mieux ne pas le faire que de le faire.
If the implementation is hard to explain, it's a bad idea.
S'il est difficile d'expliquer ce qu'est le code, c'est une mauvaise implémentation.
If the implementation is easy to explain, it may be a good idea.
Si vous pouvez facilement expliquer le contenu du code, c'est probablement une bonne implémentation.
Namespaces are one honking great idea -- let's do more of those!
Les espaces de noms sont une excellente idée et doivent être utilisés activement.
Ensuite, j'expliquerai le texte original ligne par ligne.
Beautiful is better than ugly. Beau est mieux que laid.
(Répondant: J.T. Hurley)
Avec Python, vous pouvez trouver l'engagement maximum avec juste autant de code.
def gcd(x, y):
while y:
x, y = y, x % y
return x
Plus l'algorithme est beau, plus le code est beau. Et Python peut exprimer sa beauté avec un petit nombre de lignes.
Explicit is better than implicit. Il vaut mieux clarifier que suggérer.
Ne fais pas ça.
from os import *
print(getcwd())
Permet de voir facilement à partir de quel module la fonction est fournie.
import os
print(os.getcwd())
Le Zen de Python dit:
Namespaces are one honking great idea - let's do more of those!
L'espace de noms est une excellente idée.
Ainsi, en Python, lors de l'appel d'une méthode, lors du référencement d'un champ, spécifiez self même dans la classe. Les programmeurs doivent toujours savoir quoi et où se trouve l'objet qu'ils utilisent.
Certains langages de script peuvent le faire.
test.php
<?php
$foo = "5";
echo $foo * 3;
?>
Une fois exécuté, cela devient comme ça.
$php test.php
15
Cela se produit car la chaîne de caractères est considérée comme un entier lors du calcul de la chaîne de caractères x entier. C'est ce qu'on appelle la conversion de type implicite. Cependant, en Python, c'est une erreur.
>>> foo = "5"
>>> foo+3
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
Si vous souhaitez que le résultat soit renvoyé sous forme d'entier, vous devez le spécifier.
>>> int(foo)+3
8
Simple is better than complex. Il vaut mieux être simple que compliqué.
Complex is better than complicated. Pourtant, il vaut mieux être compliqué que compliqué.
Page référencée: Que signifie «Complexe vaut mieux que compliqué»? (Répondant: EinLama)
Être compliqué ou ésotérique est un peu différent d'être compliqué.
Prenons ce code comme exemple.
counter = 0
while counter < 5:
print(counter)
counter += 1
Ce code doit être très simple à comprendre. Mais ce code est ésotérique. Deux éléments, «gérer les variables de compteur» et «afficher les valeurs avec des instructions d'impression», sont mélangés dans un code.
for i in xrange(5):
print(i)
En revanche, ce code est plus complexe que l'exemple utilisant wihle. Il existe une séparation claire entre les deux éléments de «gestion des variables de compteur» et «impression de la valeur». Si vous ne connaissez pas xrange, vous ne savez peut-être pas ce que fait ce code. Mais si vous voulez écrire du code propre, le coût pour découvrir ce qu'est xrange n'est pas si grand. Le comportement de xrange est facile à comprendre en lisant la documentation.
Plus le code est volumineux, plus la différence de gérabilité entre le code ésotérique et le code complexe est grande. Bien sûr, plus c'est simple et facile à écrire, plus c'est facile à gérer.
Beautiful is better than ugly.
Flat is better than nested.
Le nid doit être peu profond.
### Exemple
(Répondant: [S.Lott](https://stackoverflow.com/users/10661/s-lott))
Par exemple, les classes fournies par les bibliothèques Java et C ++ héritent généralement d'autres classes.
Lorsque cela se produit, vous devez réfléchir à la manière dont la classe que vous souhaitez utiliser hérite des autres classes.
Par conséquent, il devient difficile de bien comprendre et utiliser les spécifications de la bibliothèque.
Mais avec Python, vous n'avez pas besoin d'écrire __com.company.java.blah.blah__ lorsque vous utilisez des modules standard. La plupart du temps, vous devriez pouvoir utiliser __timeit__ ou __csv__. Cela est possible car l'espace de noms est construit à plat.
Sparse is better than dense.
Il vaut mieux avoir un écart que d'être encombré.
### Exemple
```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)
Quel est le plus facile à lire, le code ci-dessus ou le code ci-dessous?
N'essayez pas d'en emballer trop en une seule ligne.
Readability counts. Facile à lire, c'est bien.
(Répondant: Federico A. Ramponi)
Comparons C et Python.
#include <stdio.h>
int main(void) {
printf("Hello, world!\n");
return(0);
}
print("Hello, world!")
Même avec le même "Hello, World!", La lisibilité est complètement différente entre C et Python. Avec Python, vous pouvez voir en un coup d'œil ce que fait votre code.
Special cases aren't special enough to break the rules. Être spécial n'est pas une raison pour enfreindre les règles.
Although practicality beats purity. Cependant, en ce qui concerne l'aspect pratique, la pureté peut être perdue.
(Répondant: Federico A. Ramponi)
Python n'a pas de type "caractère uniquement" comme char. Ce n'est pas aussi spécial qu'il a besoin d'un moule spécial. Cependant, à des fins pratiques, une fonction qui prend ou renvoie un caractère de longueur 1 tel que chr ou ord est requise.
Errors should never pass silently. Ne cachez pas l'erreur, ne l'ignorez pas.
(Répondant: Ali Afshar)
Par exemple, n'écrivez pas ce code.
try:
import this
except ImportError:
pass
Indiquez clairement qu'une erreur a été détectée.
try:
import this
except ImportError:
print('this is not available')
Unless explicitly silenced. Cependant, s'il est caché exprès, ne le manquez pas.
(Répondant: Ali Afshar)
Jetons un œil à ce 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))
Une fois exécuté, cela devient comme ça.
$python silenced.py
v:0
d:{'eggs': 0, 'ham': 2, 'spam': 1}
Dans ce code, lorsqu'une clé n'existe pas, elle est définie sur la valeur par défaut. La clause except n'informe pas l'extérieur qu'une erreur s'est produite. Parce que je fais ça exprès.
In the face of ambiguity, refuse the temptation to guess. Si vous rencontrez quelque chose d'ambigu, ne devinez pas ce que cela signifie.
Quand cette déclaration conditionnelle sera-t-elle vraie?
if not a and b:
pass
Réécrivez-le comme ça
if b and not a:
pass
Ou c'est un peu maladroit, mais il vaut mieux écrire:
if (not a) and b:
pass
There should be one-- and preferably only one --obvious way to do it. Il doit y avoir un bon moyen. Il n'y a qu'une seule façon qui soit évidente pour tout le monde.
(Répondant: Federico A. Ramponi)
Il existe différentes manières de regarder les éléments d'un tableau dans l'ordre en C ++, selon le type. (Je ne suis pas familier avec C ++, alors faites-le moi savoir si vous avez un bon exemple)
Mais avec Python, c'est tout ce dont vous avez besoin. Peu importe que la cible soit un dictionnaire ou une liste, tout va bien de cette manière.
for element in sequence:
Although that way may not be obvious at first unless you're Dutch. La méthode peut être difficile à comprendre à première vue. Seuls les Néerlandais peuvent facilement comprendre.
«Néerlandais» désigne ici le développeur Python Guido van Rossum. Voir ici pour plus d'informations. Je le veux.
(Répondant: S.Lott)
Il y a eu un débat animé sur la clause if-then-else (cond? Expr1: expr2 en C). Dans ce document, Guido a proposé cela.
a = expr1 if cond else expr2
C'est le seul moyen d'écrire une clause if-then-else en Python. Cependant, il est difficile à comprendre à première vue.
Now is better than never Faites-le maintenant, plutôt que de ne pas le faire tout le temps.
(Répondant: 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')
Avez-vous remarqué ce qui ne va pas avec le code Never? Le code Never affirmera la connexion au fichier sans le fermer. L'idée de "parce que je le fermerai plus tard" donne lieu à un mauvais code. Cependant, le code maintenant fermera correctement la connexion au fichier même si une erreur se produit.
Le code Never peut également être réécrit comme suit:
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()
Mais beau vaut mieux que laid.
Beautiful is better than ugly.
Although never is often better than right now. Mais il vaut souvent mieux ne pas le faire maintenant que de le faire «immédiatement».
Une suroptimisation précoce de votre code peut souvent être une perte de temps.
Par exemple, si vous devez implémenter le tri, vous n'avez souvent pas besoin de mettre en œuvre un tri rapide à partir de zéro. Le tri rapide est généralement plus difficile à mettre en œuvre que le tri à bulles. En réalité, le tri à bulles est un problème suffisant, mais écrire avec un tri rapide dès le début est une perte de temps. Au stade du test, utilisez le tri à bulles pour le moment et réécrivez-le pour un tri rapide si nécessaire.
If the implementation is hard to explain, it's a bad idea. S'il est difficile d'expliquer ce qu'est le code, c'est une mauvaise implémentation.
If the implementation is easy to explain, it may be a good idea. Si vous pouvez facilement expliquer le contenu du code, c'est probablement une bonne implémentation.
Namespaces are one honking great idea -- let's do more of those! Les espaces de noms sont une excellente idée et doivent être utilisés activement.
(Répondant: Federico A. Ramponi, éditeur: wim)
Lorsque vous utilisez le module, écrivez comme ceci.
import module
module.spam()
import module
breakfast = module.SpamAndEggs()
N'écris pas ça.
from module import *
Vous ne pouvez écrire ceci que lors du test d'une fonction dans un terminal. Si vous écrivez ceci dans un programme normal, les noms peuvent entrer en conflit. De plus, la lisibilité est réduite car on ne sait pas à quel module appartient la fonction.
Si le nom du module ou le nom de la classe est long, utilisez comme.
import aRidiculouslyLongModuleName as short
Si vous avez des questions ou des préoccupations, veuillez commenter.
The Zen of Python Que recherchons-nous dans "Python"? What does “Complex is better than complicated” mean? An Introduction to the Zen of Python
Recommended Posts