[Nick Coghlan]
> Also, the call to __enter__() needs to be before the try/finally block (as it
> is
> in PEP 310). Otherwise we get the "releasing a lock you failed to acquire"
> problem.
I did that on purpose. There's a separate object ('abc' in the
pseudo-code of the translation) whose __enter__ and __exit__ methods
are called, and in __enter__ it can keep track of the reversible
actions it has taken.
Consider an application where you have to acquire *two* locks regularly:
def lockBoth():
got1 = got2 = False
lock1.acquire(); got1 = True
lock2.acquire(); got2 = True
yield None
if got2: lock2.release()
if got1: lock1.release()
If this gets interrupted after locking lock1 but before locking lock2,
it still has some cleanup to do.
I know that this complicates simpler use cases, and I'm not 100% sure
this is the right solution; but I don't know how else to handle this
use case.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
