[Python-Dev] PEP 340 -- concept clarification

[Tim Peters]

[Raymond]
>>>> It would be great if we could point to some code in the standard library
>>>> or in a major Python application that would be better (cleaner, faster,
>>>> or clearer) if re-written using blocks and block-iterators

[Guido]
>>> look more closely at Queue, and you'll find that the two such methods
>>> use different locks!

[Raymond]
>> I don't follow this one.   Tim's uses of not_empty and not_full are
>> orthogonal (pertaining to pending gets at one end of the queue and to
>> pending puts at the other end).  The other use of the mutex is
>> independent of either pending puts or gets; instead, it is a weak
>> attempt to minimize what can happen to the queue during a size query.
 
[Guido]
> I meant to use this as an example of the unsuitability of the
> @synchronized decorator, since it implies that all synchronization is
> on the same mutex, thereby providing a use case for the locking
> block-statement.

Queue may be a confusing example.  Older versions of Queue did indeed
use more than one mutex.  The _current_ (2.4+) version of Queue uses
only one mutex, but shared across two condition variables (`not_empty`
and `not_full` are condvars in current Queue, not locks).  Where,
e.g., current Queue.put() starts with

        self.not_full.acquire()

it _could_ say

        self.not_empty.acquire()

instead with the same semantics, or it could say

        self.mutex.acquire()

They all do an acquire() on the same mutex.  If put() needs to wait,
it needs to wait on the not_full condvar, so it's conceptually
clearest for put() to spell it the first of these ways.

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()").