Python Language
La déclaration de passage

Pourquoi voudriez-vous jamais dire à l'interprète de ne rien faire explicitement? Python a l'exigence syntaxique que les blocs de code (after if , except , def , class etc.) ne peuvent pas être vides.

Mais parfois, un bloc de code vide est utile en soi. Un bloc de class vide peut définir une nouvelle classe différente, telle qu'une exception pouvant être interceptée. Un bloc vide except peut être le moyen le plus simple d'exprimer «demander pardon plus tard» s'il n'y a rien à demander pour le pardon. Si un itérateur effectue toutes les tâches lourdes, une boucle vide for lancer l'itérateur peut être utile.

Par conséquent, si rien n'est supposé se produire dans un bloc de code, un pass est nécessaire pour qu'un tel bloc ne produise pas une IndentationError d' IndentationError . Alternativement, n'importe quelle instruction (incluant juste un terme à évaluer, comme le littéral Ellipsis ... ou une chaîne, le plus souvent une docstring) peut être utilisée, mais le pass indique clairement que rien n'est supposé se produire et n'a pas besoin être réellement évalué et (au moins temporairement) stocké en mémoire. Voici un petit recueil annoté des utilisations les plus fréquentes de pass qui ont traversé mon chemin - ainsi que quelques commentaires sur les bonnes et mauvaises pratiques.

• Ignorer (tout ou partie) un certain type d' Exception (exemple de xml ):

   try:
       self.version = "Expat %d.%d.%d" % expat.version_info
   except AttributeError:
       pass # unknown
  

  Note: Ignorer tous les types de relances, comme dans l'exemple suivant à partir de pandas , est généralement considéré comme une mauvaise pratique, car il SystemExit également les exceptions qui devraient probablement être transmises à l'appelant, par exemple KeyboardInterrupt ou SystemExit (ou même HardwareIsOnFireError . vous n'exécutez pas une boîte personnalisée avec des erreurs spécifiques définies, que certaines applications appelantes souhaitent connaître?).

   try:
       os.unlink(filename_larry)
   except:
       pass
  

  Au lieu d'utiliser au moins except Error: ou dans ce cas, except OSError: préférence except OSError: est considéré comme une pratique bien meilleure. Une analyse rapide de tous les modules python que j'ai installés m'a permis de constater que plus de 10% des modules, à l' except ...: pass , interceptaient toutes les exceptions.

• Dériver une classe d'exception qui n'ajoute pas de nouveau comportement (par exemple, dans scipy ):

   class CompileError(Exception):
       pass
  

  De même, les classes destinées à la classe de base abstraite ont souvent un __init__ vide explicite ou d'autres méthodes que les sous-classes sont supposées dériver. (p.ex. pebl )

   class _BaseSubmittingController(_BaseController):
       def submit(self, tasks): pass
       def retrieve(self, deferred_results): pass
  

• Tester ce code s'exécute correctement pour quelques valeurs de test, sans se soucier des résultats (de mpmath ):

   for x, error in MDNewton(mp, f, (1,-2), verbose=0,
                            norm=lambda x: norm(x, inf)):
       pass
  

• Dans les définitions de classe ou de fonction, un docstring est souvent déjà en place en tant qu'instruction obligatoire à exécuter dans le bloc. Dans ce cas, le bloc peut contenir pass en plus de la docstring pour dire, par exemple dans « Ceci est en effet destiné à ne rien faire. » pebl :

   class ParsingError(Exception): 
       """Error encountered while parsing an ill-formed datafile."""
       pass
  

• Dans certains cas, pass est utilisé comme un espace réservé pour dire "Cette méthode / class / if-block / ... n'a pas encore été implémentée, mais ce sera l'endroit pour le faire", bien que je préfère personnellement le littéral Ellipsis ... (REMARQUE: python-3 uniquement) afin de faire la distinction entre ceci et le «non-op» intentionnel dans l'exemple précédent. Par exemple, si j'écris un modèle en gros traits, je pourrais écrire

   def update_agent(agent):
       ... 
  

  où d'autres pourraient avoir

   def update_agent(agent):
       pass
  

  avant

   def time_step(agents):
       for agent in agents:
           update_agent(agent)
  

  pour vous rappeler de remplir la fonction update_agent ultérieurement, mais lancez des tests pour voir si le reste du code se comporte comme prévu. (Une troisième option pour ce cas est raise NotImplementedError Ceci est utile notamment pour deux cas. Soit « Cette méthode abstraite doit être mis en œuvre par chaque sous - classe, il n'y a pas moyen générique de définir dans cette classe de base » ou « Cette fonction , avec ce nom, n'est pas encore implémenté dans cette version, mais voici à quoi sa signature ressemblera ” )