Queue question

[spinner]

---------------------------------------------

A two parter newbie question I am afraid.

Am I right in thinking that using something like ...

item = a_queue.get()
print item

will not print 'item' unless or until there is an item in the queue to
retrieve. Effectively stalling the thread at the .get() instruction?

I can see that this it may be tested for, using the .empty() function
thereby allowing the code to progress if there was nothing in the
queue, but how is .not_empty used ?

Thanks in advance
---------------------------------------------

[Steve M]

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

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.

[spinner]

Ahh the penny has dropped at last. I am using the WingIDE and
..not_empty is one of the properties it exposes with it's intellisense.
As such its use is not documented. No problem.

Using the exception would more accurate - I can see that. In my simple
case the queue is a one to one link, into and out of a single thread
and so I can use the .empty() call with impunity. I can see that using
queue's may be overkill in this instance but it has been good practice
to get to know how they operate.

Being new to python I am just getting used to syntax and conventions,
your reply has clarrified the issue for me.

Thank you for posting Steve.

[Alex Martelli]

Steve M <sj******@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

[Tim Peters]

[Alex Martelli]

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

Last time it was rewritten, I put as much thought into the names of
Queue instance variables as Guido put into them originally: none.
They have always "looked like" public names, but I'm at a loss to
think of anythng sane a Queue client or extender could do with them.
Of course that's why the docs don't mention them. I suppose an
extender could make good use of `mutex` if they wanted to add an
entirely new method, say:

def get_and_put_nowait(self, new_item) :
"""Pop existing item, and push new item, atomically [blah blah blah]."""

I don't know of anyone who has done so, though. I kept the name
`mutex` intact during the last rewrite, but didn't hesitate to get rid
of the former `esema` and `fsema` attributes. Since no complaints
resulted, it's a pretty safe bet nobody was mucking with esema or
fsema before.