Guido van Rossum wrote: >> @with_template >> def closing(obj): >> try: >> yield obj >> finally: >> obj.close() >> > I just realized this has a race condition. The bytecode for the > expression closing(open("...")) must necessarily contain a bytecode > that calls open() followed by another bytecode that calls closing().
This is not a convincing point. That race condition always existed, e.g. in the traditional f = open(filename) try: process(f) finally: f.close() as you could always get an async exception between open returns and f is assigned. This isn't much of an issue, since CPython would always release the file immediately as the stack frame is cleared due to the exception. I think would should explicitly weaken our guarantees for "asynchronous" exceptions (of which we currently only have KeyboardInterrupt). The PEP should point out that an async exception between the beginning of the with statement and the assignment to the variable may or may not cause __exit__ to be called (depending on how far you are into __enter__) Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com