[Python-Dev] Proposed addition to threading module - released

Guido van Rossum guido at python.org
Tue Apr 25 01:56:54 CEST 2006


On 4/24/06, "Martin v. Löwis" <martin at v.loewis.de> 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/)


More information about the Python-Dev mailing list

AltStyle によって変換されたページ (->オリジナル) /