Une des idées de la philosophie de design de Python est "Il devrait y avoir une ... une façon évidente de le faire." (PEP 20) , mais cela ne peut pas toujours être vrai. Je fais notamment référence à (simples) si des déclarations par rapport à l'évaluation booléenne. Considérons les éléments suivants:
self.words = words or {}
3 Réponses :
"Là devrait être un seul" peut parfaitement bien être toujours vrai; C'est l'assertion positive "là-bas est un seul" qui ne peut pas être - "devrait" impliquer une cible, un objectif, pas la possibilité de toujours l'atteindre (par exemple, pour les nombres Dans votre exemple, je conviendrais que le a et b , interdisant soit b + a ou a + b serait tellement absurde qu'il ne peut tout simplement pas être sensiblement "un seul moyen" Dans ce cas).
ou est préférable dans des cas suffisamment simples (quatre lignes de faire ce qui peut être fait dans une ligne claire et lisible est un gaspillage d'espace vertical) mais pas pour un prédicat de toute complexité significative. Décider de ce qui a une "complexité significative" est, bien sûr, un appel de jugement.
(édité) bien sûr, si vous pensez améliorer la lisibilité (vous pouvez la lire à haute voix de cette façon?), vous pouvez essayer < / p>
Bien dans un cas comme ci-dessous, je vote pour l'expression conditionnelle
Vous avez raison! En fait, toute cette question a été inspirée en essayant de le faire avec une définition de classe et de trouver tous mes instances partagées le même attribut de dictionnaire.
-1: Vous ne voulez probablement pas faire cela (au moins pas en général) - Les arguments par défaut mutables peuvent vous surprendre. Voir Stackoverflow.com/Questtions/1132941 par exemple.
@Scott Griffiths: Ugh, désolé. Je n'ai pas encore souffert que je suppose que je ne l'ai pas pensé. merci pour l'URL. Donc aucun argument par défaut mutable en python. garder le -1, espère que cela m'aide à me souvenir de la leçon
@Scott: Vous descendez cette réponse parce que vous mentionnez une pratique qui n'a rien à voir avec la question? Est-ce que vous voulez dire «vous ne voulez pas faire d'arguments par défaut»?
@xtoll: J'avais Def Somesuch (auto, mots = []): Initialement, oubliant que c'est mal. avait édité le post depuis lors
Dans ce cas, je dirais que "explicite est meilleur que implicite".
Lorsque quelqu'un lit votre code, ils peuvent faire quelques hypothèses. Ils peuvent supposer que des "mots" peuvent être un dict vide ou un avec des données dedans (manquant le cas quand il n'y en a pas) Dans ce cas, ils pourraient être tentés d'optimiser votre code. Ils pourraient même avoir raison de le faire, si cela n'est pas déclaré nulle part où vous pouvez obtenir une valeur de None.
si "mots" peut en être néant, j'essaierais d'être clair à ce sujet. avec: ou éventuellement un "autre" au lieu d'une affectation inconditionnelle en premier.
Dans tous les cas, cette façon de documenter le fait que personne n'est une valeur attendue pour "mots".