[Python-ideas] `__iter__` for queues?

Cameron Simpson cs at zip.com.au
Wed Jan 20 00:09:38 CET 2010

On 19Jan2010 23:01, MRAB <python at mrabarnett.plus.com> wrote:
| Georg Brandl wrote:
| >Am 19.01.2010 21:20, schrieb cool-RR:
| >>On Tue, Jan 19, 2010 at 11:10 PM, Simon Brunning <simon at brunningonline.net>:
| >>    2010/1/19 cool-RR <cool-rr at cool-rr.com>:
| >>    > Is there a reason that queues don't have an `__iter__` method? I
| >>    > mean both `Queue.Queue` and `multiprocessing.Queue`.
| >>
| >>    Could it be made threadsafe?
| >>
| >>For me, iterating on the queue means just calling `get` repeatedly until
| >>it's empty. Now that I think about it, maybe this is not the most
| >>obvious meaning? I'm not sure now.
| >Your obvious queue iterator would call get(block=False) and stop on Empty.
| >The other obvious meaning is be to call get(block=True) forever.  IMO they
| >are both too "obvious" to make a call -- an explicit while loop is better.
| >
| To me the 'obvious' meaning is to call get(block=True) and have it raise
| Empty (actually, StopIteration) when the queue is empty and the 'sender'
| has somehow signalled that no more items will be put into the queue
| (q.finished()?). This would also eliminate the need for a sentinel!

Personally, I have long had an IterableQueue subclass, but it uses a
tunable sentinel (None by default).

But it adds a .close() method, and doesn't iterate until empty, it
iterates until closed. This is because I want to write a handler like

  for item in Q:
    ...do stuff...

and have it block if the queue is empty.

So clearly there are two reasonable approaches to the end-of-iteration
idea; extending Queue to do iteration probably would want to choose one.

So maybe two helper iteration methods might be the go: it's easy enough
to write a generator to iterate-until-empty or iterate-until-sentinel.

Cameron Simpson <cs at zip.com.au> DoD#743

... It beeped and said "Countdown initiated." Is that bad?

More information about the Python-ideas mailing list