Queue question

[Alex Martelli]

Steve M <sjmaster at gmail.com> wrote:

> According to my "Python in a Nutshell":
> 
> q.get(block=True)
> 
> is the signature, so, as you use it above, the call will hang until
> something is on the queue. If block is false and the queue is empty,
> q.get() will raise the exception Empty.
> 
> q.get_nowait is apparently synonymous with q.get(block=False)

Yep.  Nowadays you can also have an optional timeout= argument to the
.get method, to obtain the Empty exception only after the get attempt
has waited for some time for some item to arrive.


> q.not_empty, if it existed, I expect would be true just in case there
> was at least one item in the queue. But according to my book there is
> q.empty and q.full, which is true when the queue has the maximum
> allowed number of items (a value specified when the queue is created).

not_empty and not_full are not methods but rather instances of the
threading.Condition class, which gets waited on and notified
appropriately.  I'm not entirely sure exactly WHAT one is supposed to do
with the Condition instances in question (I'm sure there is some design
intent there, because their names indicate they're public); presumably,
like for the Lock instance named 'mutex', they can be used in subclasses
that do particularly fiendish things... but I keep planning not to cover
them in the 2nd edition of the Nutshell (though there I _will_ cover the
idea of subclassing Queue to implement queueing disciplines other than
FIFO without needing to worry about synchronization, which I had skipped
in the 1st edition).

 
> Also, I don't think you can rely on q.empty in the way you may expect.
> For example, another thread can empty the queue between the time you
> test whether q.empty is false and the time you call q.get.

Absolutely true.  "Anything can happen" right after you call q.empty(),
so the existence of that method isn't a good idea (it's somewhat of an
"attractive nuisance" -- its existence prompts some programmers who
don't read docs to try and use it, possibly producing unreliable code
which works when tested but silently breaks in real-life use).


Alex