Qu'entend-on par «utilisation du principe EAFP» en Python? Pouvez-vous donner des exemples?
Qu'entend-on par «utilisation du principe EAFP» en Python? Pouvez-vous donner des exemples?
Réponses:
Extrait du glossaire :
Plus facile de demander pardon que la permission. Ce style de codage Python commun suppose l'existence de clés ou d'attributs valides et intercepte les exceptions si l'hypothèse s'avère fausse. Ce style propre et rapide se caractérise par la présence d' un grand nombre
try
etexcept
déclarations. La technique contraste avec le style LBYL commun à de nombreux autres langages tels que C.
Un exemple serait une tentative d'accès à une clé de dictionnaire.
EAFP:
try:
x = my_dict["key"]
except KeyError:
# handle missing key
LBYL:
if "key" in my_dict:
x = my_dict["key"]
else:
# handle missing key
La version LBYL doit rechercher la clé dans le dictionnaire deux fois et peut également être considérée comme légèrement moins lisible.
x
lorsque la clé n'existe pas: x = mydict.get('key')
retournera None
si 'key'
n'est pas dans my_dict
; vous pouvez également le faire .get('key', <something>)
, et x se verra attribuer ce quelque chose si la clé n'est pas dans le dictionnaire. dict.setdefault()
et collections.defaultdict
sont également de bonnes choses pour éviter les excès de code.
except KeyError
ainsi que AttributeError
sont simples mais certains des pires exemples. Tant de fois, j'étais coincé except AttributeError
en train de déboguer quelque chose parce que j'étais mal placé, ce qui finit par attraper une erreur d'attribut erronée plus profondément dans la chaîne. De meilleurs exemples que je pense sont: try: open() ... except: IOError
. Outry: parseLine() ... except ParseError
Je vais essayer de l'expliquer avec un autre exemple.
Ici, nous essayons d'accéder au fichier et d'imprimer le contenu dans la console.
Nous pourrions vouloir vérifier si nous pouvons accéder au fichier et si nous le pouvons, nous l'ouvrirons et en imprimerons le contenu. Si nous ne pouvons pas accéder au fichier, nous frapperons la else
partie. La raison pour laquelle il s'agit d'une condition de concurrence est que nous effectuons d'abord une vérification d'accès. Au moment où nous atteignons, with open(my_file) as f:
nous ne pouvons peut-être plus y accéder en raison de problèmes d'autorisation (par exemple, un autre processus obtient un verrou de fichier exclusif). Ce code générera probablement une erreur et nous ne serons pas en mesure de détecter cette erreur car nous pensions pouvoir accéder au fichier.
import os
my_file = "/path/to/my/file.txt"
# Race condition
if os.access(my_file, os.R_OK):
with open(my_file) as f:
print(f.read())
else:
print("File can't be accessed")
Dans cet exemple, nous essayons simplement d'ouvrir le fichier et si nous ne pouvons pas l'ouvrir, il lancera un fichier IOError
. Si nous le pouvons, nous ouvrirons le fichier et imprimerons le contenu. Donc, au lieu de demander quelque chose, nous essayons de le faire. Si cela fonctionne, tant mieux! Si ce n'est pas le cas, nous détectons l'erreur et la gérons.
# # No race condition
try:
f = open(my_file)
except IOError as e:
print("File can't be accessed")
else:
with f:
print(f.read())
Je l'appelle «programmation optimiste». L'idée est que la plupart du temps, les gens feront ce qu'il faut et les erreurs devraient être rares. Donc, commencez par coder pour que la «bonne chose» se produise, puis détectez les erreurs si ce n'est pas le cas.
Mon sentiment est que si un utilisateur commet des erreurs, c'est lui qui devrait en subir les conséquences. Les personnes qui utilisent l'outil de la bonne manière sont accélérées.