[Python-Dev] PEP 340 -- concept clarification

[Tim Peters]

[Tim]
>> Because Queue does use condvars now instead of plain locks, I wouldn't
>> approve of any gimmick purporting to hide the acquire/release's in
>> put() or get():  that those are visible is necessary to seeing that
>> the _condvar_ protocol is being followed ("must acquire() before
>> wait(); must be acquire()'ed during notify(); no path should leave the
>> condvar acquire()d 'for a long time' before a wait() or release()").

[Guido]
> So you think that this would be obscure? A generic condition variable
> use could look like this:
> 
>    block locking(self.condvar):
>        while not self.items:
>            self.condvar.wait()
>        self.process(self.items)
>        self.items = []
> 
> instead of this:
> 
>    self.condvar.acquire()
>    try:
>        while not self.items:
>            self.condvar.wait()
>        self.process(self.items)
>        self.items = []
>    finally:
>        self.condvar.release()
>
> I find that the "block locking" version looks just fine; it makes the
> scope of the condition variable quite clear despite not having any
> explicit acquire() or release() calls (there are some abstracted away
> in the wait() call too!).

Actually typing it all out like that makes it hard to dislike <wink>. 
Yup, that reads fine to me too.

I don't think anyone has mentioned this yet, so I will:  library
writers using Decimal (or more generally HW 754 gimmicks) have a need
to fiddle lots of thread-local state ("numeric context"), and must
restore it no matter how the routine exits.  Like "boost precision to
twice the user's value over the next 12 computations, then restore",
and "no matter what happens here, restore the incoming value of the
overflow-happened flag".  It's just another instance of temporarily
taking over a shared resource, but I think it's worth mentioning that
there are a lot of things "like that" in the world, and to which
decorators don't really sanely apply.