Phillip J. Eby wrote: > Ow. My head hurts. :) Seriously, though, wouldn't it make more sense > to put the 'with async_exceptions_blocked()' in the __init__ or > __enter__ of 'critical_resource'? Or am I still missing something?
Heck, I *suggested* the trick, and still had to look at it a half dozen times, including frontways, and backways and upside down in order to satisfy myself that it actually addressed all the issues Guido and I had been talking about. Anyway, the kicker is that (in the rare cases where it matters), you want asynchronous exceptions blocked before EXPR gets evaluated, and then unblocked again after the try/finally has been entered, but before BLOCK starts evaluating. I believe the only real way to do that deterministically is to do the blocking and unblocking of asynchronous exceptions inline - when the asynchronous exception occurs, either the critical resource hasn't been acquired yet, or we are inside a try/finally that will ensure its release. Trying to push the blocking/unblocking inside a template like safe_acquisition actually results in the loss of that determinism, since it may be the case that safe_acquisition itself is not finalised properly (the asynchronous exception goes off prior to entry of the relevant try/finally block). However, the generator object's __del__ method will clean things up eventually. Anyway, the main point is that with statements won't make any more guarantees about this than try/finally statements do - but they do provide the tool to deal with it reasonably cleanly when it matters (most of the time the asynchronous error will indicate program shutdown, and the remote possibility of misbehaviour won't really matter in practice). Cheers, Nick. P.S. I've included this trick as part of the Wiki discussion, meaning my last PEP 343 question has been well and truly dealt with. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ 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