manager - ¿Es Python*con*instrucción exactamente equivalente a un intento-(excepto)-finalmente bloquear?

with python español

Question

Sé que esto fue ampliamente discutido, pero todavía no puedo encontrar una respuesta para confirmar esto: es la sentencia with idéntica a llamar al mismo código en un bloque try - (excepto) -finally, donde cualquiera que se defina en la función __exit__ de El gestor de contexto se coloca en el bloque finalmente?

Por ejemplo, ¿estos 2 fragmentos de código hacen exactamente lo mismo?

import sys
from contextlib import contextmanager

@contextmanager
def open_input(fpath):
    fd = open(fpath) if fpath else sys.stdin
    try:
        yield fd
    finally:
        fd.close()

with open_input("/path/to/file"):
    print "starting to read from file..."

lo mismo que:

def open_input(fpath):
    try:
        fd = open(fpath) if fpath else sys.stdin
        print "starting to read from file..."
    finally:
        fd.close()

open_input("/path/to/file")

¡Gracias!

Answer 1

Voy a dejar de lado las menciones de alcance, porque en realidad no es muy relevante.

Según PEP 343 ,

with EXPR as VAR:
    BLOCK

traduce a

mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value  # Only if "as VAR" is present
        BLOCK
    except:
        # The exceptional case is handled here
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
        # The exception is swallowed if exit() returns true
finally:
    # The normal and non-local-goto cases are handled here
    if exc:
        exit(mgr, None, None, None)

Como puede ver, type(mgr).__enter__ se llama como espera, pero no dentro del try .

type(mgr).__exit__ se llama en exit. La única diferencia es que cuando hay una excepción, se toma la ruta if not exit(mgr, *sys.exc_info()) . Esto permite la introspección y el silencio de los errores, a diferencia de lo que puede hacer una cláusula finally .

contextmanager no complica mucho esto. Es solo

def contextmanager(func):
    @wraps(func)
    def helper(*args, **kwds):
        return _GeneratorContextManager(func, *args, **kwds)
    return helper

Luego mira la clase en cuestión:

class _GeneratorContextManager(ContextDecorator):
    def __init__(self, func, *args, **kwds):
        self.gen = func(*args, **kwds)

    def __enter__(self):
        try:
            return next(self.gen)
        except StopIteration:
            raise RuntimeError("generator didn''t yield") from None

    def __exit__(self, type, value, traceback):
        if type is None:
            try:
                next(self.gen)
            except StopIteration:
                return
            else:
                raise RuntimeError("generator didn''t stop")
        else:
            if value is None:
                value = type()
            try:
                self.gen.throw(type, value, traceback)
                raise RuntimeError("generator didn''t stop after throw()")
            except StopIteration as exc:
                return exc is not value
            except:
                if sys.exc_info()[1] is not value:
                    raise

Código no importante ha sido elidido.

Lo primero que se debe tener en cuenta es que si hay varios yield , este código generará un error.

Esto no afecta notablemente al flujo de control.

Considere __enter__ .

try:
    return next(self.gen)
except StopIteration:
    raise RuntimeError("generator didn''t yield") from None

Si el administrador de contexto estaba bien escrito, esto nunca se romperá de lo que se espera.

Una diferencia es que si el generador lanza StopIteration , se StopIteration un error diferente ( RuntimeError ). Esto significa que el comportamiento no es totalmente idéntico al normal si está ejecutando un código completamente arbitrario.

Considere un __exit__ no __exit__ :

if type is None:
    try:
        next(self.gen)
    except StopIteration:
        return
    else:
        raise RuntimeError("generator didn''t stop")

La única diferencia es como antes; Si su código lanza StopIteration , afectará al generador y, por lo tanto, el decorador de contextmanager lo malinterpretará.

Esto significa que:

from contextlib import contextmanager

@contextmanager
def with_cleanup(func):
    try:
        yield
    finally:
        func()

def good_cleanup():
    print("cleaning")

with with_cleanup(good_cleanup):
    print("doing")
    1/0
#>>> doing
#>>> cleaning
#>>> Traceback (most recent call last):
#>>>   File "", line 15, in <module>
#>>> ZeroDivisionError: division by zero

def bad_cleanup():
    print("cleaning")
    raise StopIteration

with with_cleanup(bad_cleanup):
    print("doing")
    1/0
#>>> doing
#>>> cleaning

Lo que es poco probable que importe, pero podría.

Finalmente:

else:
    if value is None:
        value = type()
    try:
        self.gen.throw(type, value, traceback)
        raise RuntimeError("generator didn''t stop after throw()")
    except StopIteration as exc:
        return exc is not value
    except:
        if sys.exc_info()[1] is not value:
            raise

Esto plantea la misma pregunta sobre StopIteration , pero es interesante notar esa última parte.

if sys.exc_info()[1] is not value:
    raise

Esto significa que si la excepción no se maneja, el rastreo no se modificará. Si se manejó pero existe un nuevo rastreo, se levantará en su lugar.

Esto coincide perfectamente con la especificación.

TL; DR

• with es en realidad un poco más poderoso que un try...finally en el que el introspección puede y los errores de silencio.

• Tenga cuidado con StopIteration , pero de lo contrario está bien usando @contextmanager para crear administradores de contexto.