¿'Finalmente' siempre se ejecuta en Python?

Para cualquier posible bloque de intentar finalmente en Python, ¿se garantiza que el finallybloque siempre se ejecutará?

Por ejemplo, digamos que regreso mientras estoy en un exceptbloque:

try:
    1/0
except ZeroDivisionError:
    return
finally:
    print("Does this code run?")

O tal vez resubo un Exception:

try:
    1/0
except ZeroDivisionError:
    raise
finally:
    print("What about this code?")

Las pruebas muestran que finallyse ejecuta para los ejemplos anteriores, pero imagino que hay otros escenarios en los que no he pensado.

¿Existe algún escenario en el que un finallybloque no se pueda ejecutar en Python?

"Garantizado" es una palabra mucho más fuerte de lo que finallymerece cualquier implementación . Lo que está garantizado es que si ejecución fluye fuera de toda la try- finallyconstrucción, pasará a través de la finallyque lo haga. Lo que no está garantizado es que la ejecución saldrá del try- finally.

• A finallyen un generador o una rutina asíncrona podría no ejecutarse nunca , si el objeto nunca se ejecuta hasta la conclusión. Hay muchas formas en que podría suceder; Aquí hay uno:

  def gen(text):
      try:
          for line in text:
              try:
                  yield int(line)
              except:
                  # Ignore blank lines - but catch too much!
                  pass
      finally:
          print('Doing important cleanup')
  
  text = ['1', '', '2', '', '3']
  
  if any(n > 1 for n in gen(text)):
      print('Found a number')
  
  print('Oops, no cleanup.')
  

  Tenga en cuenta que este ejemplo es un poco complicado: cuando se recolecta basura en el generador, Python intenta ejecutar el finallybloque lanzando una GeneratorExitexcepción, pero aquí capturamos esa excepción y luego yieldnuevamente, en cuyo punto Python imprime una advertencia ("generador ignorado GeneratorSalir ") y se rinde. Consulte PEP 342 (Corutinas a través de generadores mejorados) para obtener más detalles.

  Otras formas en que un generador o corrutina podrían ejecutarse a la conclusión incluyen si el objeto es simplemente nunca GC'ed (sí, eso es posible, incluso en CPython), o si un async with awaits en __aexit__, o si el objeto awaits o yields en un finallybloque. Esta lista no pretende ser exhaustiva.

• A finallyen un subproceso de demonio podría no ejecutarse nunca si todos los subprocesos que no son de demonio salen primero.

• os._exitdetendrá el proceso inmediatamente sin ejecutar finallybloques.

• os.forkpuede hacer que los finallybloques se ejecuten dos veces . Además de los problemas normales que esperaría de que las cosas sucedan dos veces, esto podría causar conflictos de acceso concurrentes (bloqueos, bloqueos, ...) si el acceso a los recursos compartidos no está sincronizado correctamente .

  Dado que multiprocessingusa fork-without-exec para crear procesos de trabajo cuando usa el método fork start (el predeterminado en Unix), y luego llama os._exital trabajador una vez que el trabajo del trabajador está terminado, finallyy la multiprocessinginteracción puede ser problemática ( ejemplo ).

• Una falla de segmentación de nivel C evitará que los finallybloques se ejecuten.
• kill -SIGKILLevitará que los finallybloques se ejecuten. SIGTERMy SIGHUPtambién evitará que los finallybloques se ejecuten a menos que instale un controlador para controlar el apagado usted mismo; de forma predeterminada, Python no maneja SIGTERMo SIGHUP.
• Una excepción en finallypuede evitar que se complete la limpieza. Un caso particularmente digno de mención es si el usuario presiona control-C justo cuando comenzamos a ejecutar el finallybloque. Python generará un KeyboardInterrupty omitirá todas las líneas del finallycontenido del bloque. ( KeyboardInterrupt-El código seguro es muy difícil de escribir).
• Si la computadora pierde energía, o si hiberna y no se activa, los finallybloques no se ejecutarán.

El finallybloque no es un sistema de transacciones; no proporciona garantías de atomicidad ni nada por el estilo. Algunos de estos ejemplos pueden parecer obvios, pero es fácil olvidar que tales cosas pueden suceder y depender finallydemasiado de ellos.

Si. Finalmente siempre gana.

La única forma de derrotarlo es detener la ejecución antes de que finally:tenga la oportunidad de ejecutarse (por ejemplo, bloquear el intérprete, apagar su computadora, suspender un generador para siempre).

Imagino que hay otros escenarios en los que no he pensado.

Aquí hay algunos más en los que quizás no haya pensado:

def foo():
    # finally always wins
    try:
        return 1
    finally:
        return 2

def bar():
    # even if he has to eat an unhandled exception, finally wins
    try:
        raise Exception('boom')
    finally:
        return 'no boom'

Dependiendo de cómo abandone el intérprete, a veces puede "cancelar" finalmente, pero no así:

>>> import sys
>>> try:
...     sys.exit()
... finally:
...     print('finally wins!')
... 
finally wins!
$

Usando lo precario os._exit(esto se enmarca en "estrellar al intérprete" en mi opinión):

>>> import os
>>> try:
...     os._exit(1)
... finally:
...     print('finally!')
... 
$

Actualmente estoy ejecutando este código, para probar si finalmente se ejecutará después de la muerte térmica del universo:

try:
    while True:
       sleep(1)
finally:
    print('done')

Sin embargo, todavía estoy esperando el resultado, así que vuelva a consultar aquí más tarde.

Según la documentación de Python :

No importa lo que haya sucedido anteriormente, el bloque final se ejecuta una vez que el bloque de código está completo y se manejan las excepciones que surgen. Incluso si hay un error en un controlador de excepciones o en el bloque else y se genera una nueva excepción, el código en el bloque final aún se ejecuta.

También debe tenerse en cuenta que si hay varias declaraciones de retorno, incluida una en el bloque finalmente, el retorno del bloque finalmente es el único que se ejecutará.

Bueno, sí y no.

Lo que está garantizado es que Python siempre intentará ejecutar el bloque finalmente. En el caso de que regrese del bloque o genere una excepción no detectada, el bloque finalmente se ejecuta justo antes de regresar o generar la excepción.

(lo que podría haber controlado usted mismo simplemente ejecutando el código en su pregunta)

El único caso que puedo imaginar en el que el bloque finalmente no se ejecutará es cuando el propio intérprete de Python se bloquea, por ejemplo, dentro del código C o debido a un corte de energía.

Encontré este sin usar una función de generador:

import multiprocessing
import time

def fun(arg):
  try:
    print("tried " + str(arg))
    time.sleep(arg)
  finally:
    print("finally cleaned up " + str(arg))
  return foo

list = [1, 2, 3]
multiprocessing.Pool().map(fun, list)

El sueño puede ser cualquier código que se ejecute durante períodos de tiempo inconsistentes.

Lo que parece estar sucediendo aquí es que el primer proceso paralelo que finaliza deja el bloque try con éxito, pero luego intenta devolver de la función un valor (foo) que no se ha definido en ninguna parte, lo que provoca una excepción. Esa excepción mata el mapa sin permitir que los otros procesos alcancen sus bloques finales.

Además, si agrega la línea bar = bazzjusto después de la llamada sleep () en el bloque try. Luego, el primer proceso para llegar a esa línea arroja una excepción (porque bazz no está definido), lo que hace que se ejecute su propio bloque finalmente, pero luego mata el mapa, lo que hace que los otros bloques de prueba desaparezcan sin llegar a sus bloques finalmente, y el primer proceso tampoco llegó a su declaración de devolución.

Lo que esto significa para el multiprocesamiento de Python es que no puede confiar en el mecanismo de manejo de excepciones para limpiar los recursos en todos los procesos si incluso uno de los procesos puede tener una excepción. Sería necesario un manejo de señales adicional o la administración de los recursos fuera de la llamada de mapa de multiprocesamiento.