Python Language
La declaración de pase

¿Por qué querría decirle al intérprete que no haga nada explícitamente? Python tiene el requisito sintáctico de que los bloques de código (después de, if , except , def , class , etc.) no pueden estar vacíos.

Pero a veces un bloque de código vacío es útil en sí mismo. Un bloque de class vacío puede definir una nueva clase diferente, como una excepción que se puede capturar. Un bloque de except vacío puede ser la forma más simple de expresar "pedir perdón más tarde" si no hubiera nada por lo que pedir perdón. Si un iterador hace todo el trabajo pesado, un iterador vacío for ejecutar el iterador puede ser útil.

Por lo tanto, si no se supone que ocurra nada en un bloque de código, se necesita un pass para que dicho bloque no produzca un IndentationError . Alternativamente, se puede usar cualquier declaración (incluido solo un término para ser evaluado, como el literal de Ellipsis ... o una cadena, más a menudo una cadena de documentación), pero el pass deja claro que en realidad no se supone que suceda nada, y no es necesario para ser realmente evaluado y (al menos temporalmente) almacenado en la memoria. Aquí hay una pequeña colección anotada de los usos más frecuentes del pass que se cruzó en mi camino, junto con algunos comentarios sobre buenas y malas prácticas.

• Ignorar (todo o) un cierto tipo de Exception (ejemplo de xml ):

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

  Nota: ignorar todos los tipos de aumentos, como en el siguiente ejemplo de pandas , generalmente se considera una mala práctica, ya que también detecta excepciones que probablemente deberían transmitirse a la persona que llama, por ejemplo, KeyboardInterrupt o SystemExit (o incluso HardwareIsOnFireError - ¿Cómo lo sabe?) no se está ejecutando en un cuadro personalizado con errores específicos definidos, que alguna aplicación de llamada querría conocer?).

   try:
       os.unlink(filename_larry)
   except:
       pass
  

  En su lugar, usar al menos except Error: o en este caso, preferiblemente, except OSError: se considera una práctica mucho mejor. Un análisis rápido de todos los módulos de python que he instalado me dio el hecho de que más del 10% de todos, except ...: pass declaraciones de except ...: pass detectan todas las excepciones, por lo que sigue siendo un patrón frecuente en la programación de python.

• Derivar una clase de excepción que no agrega un comportamiento nuevo (por ejemplo, en scipy ):

   class CompileError(Exception):
       pass
  

  De manera similar, las clases destinadas a la clase base abstracta a menudo tienen un __init__ vacío explícito u otros métodos que se supone que derivan las subclases. (por ejemplo, pebl )

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

• La prueba de que el código se ejecuta correctamente para unos pocos valores de prueba, sin preocuparse por los resultados (de mpmath ):

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

• En las definiciones de clase o función, a menudo una cadena de documentación ya está implementada como la declaración obligatoria que debe ejecutarse como la única cosa en el bloque. En tales casos, el bloque puede contener un pass además de la cadena de documentación para decir "Esto no pretende hacer nada", por ejemplo, en pebl :

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

• En algunos casos, el pass se utiliza como marcador de posición para decir "Este método / class / if-block / ... no se ha implementado todavía, pero este será el lugar para hacerlo", aunque personalmente prefiero el literal de Ellipsis ... (NOTA: solo python-3) para diferenciar estrictamente entre esto y el "no-op" intencional en el ejemplo anterior. Por ejemplo, si escribo un modelo a grandes rasgos, podría escribir

   def update_agent(agent):
       ... 
  

  donde otros podrían tener

   def update_agent(agent):
       pass
  

  antes de

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

  como un recordatorio para completar la función update_agent en un punto posterior, pero ejecute algunas pruebas para ver si el resto del código se comporta como se esperaba. (Una tercera opción para este caso es raise NotImplementedError . Esto es útil en particular para dos casos: “Este método abstracto debe ser implementado por cada subclase, no hay una forma genérica de definirlo en esta clase base” , o “Esta función , con este nombre, aún no está implementado en esta versión, pero este es el aspecto que tendrá su firma ” )