Guido van Rossum wrote: > Tim is right, the UNLOCK/LOCK part is implied in the wait() call. > However, the wait() implementation really *does* provide a use case > for the primitive operation that Nick proposed, and it can't be > refactored to remove the pattern Martin disapproves of (though of > course the existing try/finally is fine). I'm not sure if the use case > is strong enough to warrant adding it; I think it's fine not to > support it directly.
Ah, you mean that the wait implementation *itself* should use the unlocked() context (which calls release on enter, and acquire on exit). That wouldn't work, as _Condition.wait doesn't use release/enter, but _release_save/_acquire_restore. So the unlocked context couldn't be used there if it existed. 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
