On 4/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Tim Peters wrote: > > Does > > > > with cv: > > > > work to replace the outer (== only) acquire/try/finally/release dance? > > Indeed it does - although implemented in a somewhat convoluted way: > A lock *is* a context (or is that "context manager"), i.e. it implements > > def __context__(self): return self > __enter__=acquire > def __exit__(self,*args): return self.release() #roughly > > A _Condition *has* a lock, so it could become the context (manager?) > through > > def __context__(self): return self.lock > > However, instead of doing that, it does > > def __context__(self): return self > # roughly: __enter__ is actually set in __init__ to self.lock.acquire > def __enter__(self): > return self.acquire() > def __exit__(self): > return self.release > > Looks somewhat redundant to me, but correct.
Thanks -- I didn't see the shortcut when I coded this. I'll fix it. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
