Discussion :

[Sve@r]

Bonjour à tous

J'ai vu sur sais plus quel site de conseils Python l'auteur indiquer dans un blog qu'il valait mieux demander pardon que permission.

Par exemple, pour traiter un fichier, il conseillait de l'ouvrir sans se poser de question et intercepter l'IOError éventuel plutôt que de faire des tests préalables pour savoir s'il existe et si on a le droit de l'ouvrir. Un des arguments était qu'entre les tests et l'ouverture, la situation pouvait changer.

Et donc je venais ici demander l'avis des pros. Parce que moi, j'ai plutôt l'habitude de faire des tests préalables avant de faire mon truc plutôt que faire mon truc en try/except (je ne dis pas que je ne fais pas de try/except mais je les faits plutôt lorsque j'accède à des ressources lourdes et évolutives par nature, comme par exemple une bdd).

Et donc son argument me titille un peu...

[VinsS]

Salut,

Le try-except est effectivement la méthode recommandée en Python.

Tout cela est décrit dans le glossaire:
https://docs.python.org/3/glossary.h...sary#term-eafp
https://docs.python.org/3/glossary.h...sary#term-lbyl

[wiztricks]

Salut,

Par exemple, pour traiter un fichier, il conseillait de l'ouvrir sans se poser de question et intercepter l'IOError éventuel plutôt que de faire des tests préalables pour savoir s'il existe et si on a le droit de l'ouvrir. Un des arguments était qu'entre les tests et l'ouverture, la situation pouvait changer.

C'est une bonne raison. Et on a même désigné ce cas particulier de "race condition" par TOCTOU bug.
Une autre raison est que tester les droits d’accès dépend de l'environnement (système, disque réseau,...) et donc anticiper de le faire "proprement" dans tous les cas est bien plus/trop compliqué que d'essayer et attraper l'erreur.

Parce que moi, j'ai plutôt l'habitude de faire des tests préalables avant de faire mon truc plutôt que faire mon truc en try/except (je ne dis pas que je ne fais pas de try/except mais je les faits plutôt lorsque j'accède à des ressources lourdes et évolutives par nature, comme par exemple une bdd).

EAFP (Easier to ask for forgiveness than permission) vs LBYL (Look before you leap)?
Pour se poser la question, il faut que l'objet auquel on accède soit "partagé" et puisse changer entre le moment où on teste et le moment où on y accède (les fichiers sont un bon exemple).
La documentation donne cet exemple:
LBYL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    ...
    if key in mapping: 
        return mapping[key]

que se passe-t-il si un thread détruit la clef entre ces deux instructions?
On va avoir KeyError... donc si on écrit:
EAFP:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    ...
    try: 
        return mapping[key]
    except KeyError:
        return None

on traite le cas - et çà évite au programme de planter pour une exception qu'il n'a pas attrapé -.
Avec Python on préférera sans doute écrire: return mapping.get(key, None).

Maintenant, si l'objet partagé est une classe utilisateur dans laquelle une variable dépend d'autres, le plus simple restera de protéger les accès avec un verrou pour assurer la cohérence des différentes valeurs (i.e. LBYL). Car si on veut faire du EAFP, il faut ajouter plein de code pour détecter et reprendre l'opération (comme on le fait dans les techniques d'optimistic concurrency control).

- W

[moons17]

Pour ma part je fait les tests préalables et catégorise les erreurs dans des fichiers de log pour faciliter l'exploitation des programmes en production.
mon cas le plus fréquent est de 'batcher' un script sur une multitude de machine , de centraliser le résultat dans un seul fichier de log de gérer l'existence du fichier de sortie, le lock , de parametrer en xml la config etc etc
rien de plus frustrant que de passer des heures à chercher à cause d'un référentiel dont certaines machines n'existant plus sur des sites distants...ou un changement dans les répertoires réseau par exemple
donc il faut balancer le cout de dev de la complexité des tests d’accès au pertes d'exploitation
la situation entre les tests et l’accès peut changer en effet cependant si les instructions sont proche (en microseconde ) le risque est réduit mais non nulle ce qui n’exonère pas de faire un try lors de l’accès ça sera toujours mieux que d'avoir une application "industrialisée" ( sous windev) qui te sort un division par 0 lorsque tu la déploies sur un windows 7 à la place de xp ...et d'un dev qui s'en défend en disant qu'il se fout du système.( vu en production )

[wiztricks]

la situation entre les tests et l’accès peut changer en effet cependant si les instructions sont proche (en microseconde ) le risque est réduit mais non nulle ce qui n’exonère pas de faire un try lors de l’accès

écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if os.path.exists('fichier.xyz'):
   try:
          f = open('fichier.xyz')
          ...
   except FileNotFoundError as e:
          ...

fonctionne mais ne sert à pas grand chose sinon la jouer "ceinture et bretelles".

- W

[Sve@r]

Merci beaucoup. Super sympa
Bon ça m'énerve un peu de voir que j'ai encore tout fait à l'envers mais c'est pas grave, au moins je suis fixé

ça sera toujours mieux que d'avoir une application "industrialisée" ( sous windev) qui te sort un division par 0 lorsque tu la déploies sur un windows 7 à la place de xp ...

Je ne vois pas trop en quoi le fait de passer de xp à w7 entraine une division par 0... mais bon c'est peut-être une division d'une valeur quelconque par la fiabilité de l'OS...

[Pyramidev]

J'ai vu sur sais plus quel site de conseils Python l'auteur indiquer dans un blog qu'il valait mieux demander pardon que permission.

Par exemple, pour traiter un fichier, il conseillait de l'ouvrir sans se poser de question et intercepter l'IOError éventuel plutôt que de faire des tests préalables pour savoir s'il existe et si on a le droit de l'ouvrir. Un des arguments était qu'entre les tests et l'ouverture, la situation pouvait changer.

Pour les fichiers, il a entièrement raison.

Cependant, pour lire une entrée dans un dictionnaire et gérer explicitement le cas où la clef est absente, si le dictionnaire n'a pas été explicitement prévu pour pouvoir être modifié soudainement par un autre thread, alors le choix entre EAFP (except KeyError) et LBYL (if key in mapping) n'a pas vraiment d'importance. Choisis ce que tu juges être le plus lisible.

La documentation de Python de LBYL dit :

In a multi-threaded environment, the LBYL approach can risk introducing a race condition between “the looking” and “the leaping”. For example, the code, if key in mapping: return mapping[key] can fail if another thread removes key from mapping after the test, but before the lookup. This issue can be solved with locks or by using the EAFP approach.

Mais, partager un dictionnaire muable sans verrou entre plusieurs threads, ce n'est pas un cas habituel. À moins de chercher les ennuis, il ne faut pas le faire sans bonne raison. Et si on le fait pour de mauvaises raisons, ce n'est pas le principe EAFP qui va éviter les bogues.

Par exemple, admettons qu'un objet de configuration contienne un dictionnaire qui permet de configurer différents trucs, par exemple la langue. Admettons aussi que l'on exécute, dans plusieurs threads, des tâches qui dépendent de la configuration. Si un utilisateur édite la configuration et que cela a pour effet qu'une tâche en cours change soudainement de comportement de manière incohérente et non prévue, par exemple en commençant à écrire du texte en français puis en écrivant le reste en espagnol, alors c'est un bogue. Choisir EAFP plutôt que LBYL pour lire une clef d'un dictionnaire n'évitera pas le bogue. Si la configuration est muable à tout moment, alors la solution normale est que, au début de la tâche, on copie la partie de la configuration qui est utile à la tâche et on passe cette copie à la tâche, qui est alors la seule à lire cette copie. Comme elle est la seule à la lire, il n'y a plus de risques d'accès concurrent. Si un utilisateur édite la configuration, cela n'impactera que les tâches qui n'ont pas encore été lancées, ce qui est généralement ce que l'on veut.