RetroSearch Browse

Tue Apr 25 01:56:54 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/064311.html

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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064311.html below:

[Python-Dev] Proposed addition to threading module