Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
I prefer the current API because it makes the blocking step explicit. That
isn't the kind of thing that should be hidden behind a "for" or buried in
another tool that accepts an iterable argument, sorted(q), for example.
Also, the get() method supports two arguments "block" and "timeout" which would
be inaccessible by a iterator.
The typical use case for queue objects is to process the gets one-at-a-time,
blocking until a job arrives. Queues typically start out empty. And if they
become empty later, it doesn't usually mean that there will be no more job
requests. This would make it awkward to use the proposed feature in real code
without introducing an unnecessary extra level of nesting.
-- Code with current API --
while True:
job = q.get()
work(job)
-- Code with proposed API --
while True: # Needed to restart when the queue is empty.
for job in q: # Consumes all currently available jobs.
work(job) # Now nested two layers deep.
sleep(0.1) # Prevent spin-wait bug.
For most users, the proposed feature would likely be a distraction that leads
them away from the cleaner, lower overhead solution with an explicit get().
Also, the spin-wait bug is hard to see during code review or debugging.
FWIW, there is a race-condition in your definition of __next__(). The LBYL
logic should probably be replaced with EAFP logic putting a get_nowait() inside
a try/except.
I suggest taking this to the python-ideas mail list to discuss the pros and
cons. There are cases where a for-loop would look nicer than what we have now,
so people might find the proposal acceptable despite all the problems listed
above.
I'll mark this as closed. If the idea gains traction on the mail list, feel
free to re-open.
----------
resolution: -> later
stage: -> resolved
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41339>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
