Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:

I've put some more thought into this and have discussed it with another core 
developer.  While the idea was inspired, I think we should decline the API 
expansion.

When I last talked with Guido about this module, he opined that he didn't want 
to module to get further into the business of moderating between the producer 
and consumer, that it should focus on its core task of being a one-way 
thread-safe message queue.  

I agree that users do craft various ways of communicating via sentinel objects; 
however, there is no one pattern that dominates so much that it warrants 
deforming the API to accommodate.  FWIW, I use email as the basis for my mental 
model of how Queue is used.  With email, we don't don't need a special part of 
the API to communicate that we're not going to send messages any more; instead, 
we either stop sending messages or send a farewell message.

Of the two ideas, making queues iterable is more plausible.  However, it 
doesn't fit will common ways of using a queue.  For non-blocking queues it 
makes zero sense.  For daemon threads that block until sent a message, the 
usual pattern is while True loop that blocks on a get().  In such a case, a 
for-loop might be more compact but doesn't reflect how we think about the 
problem (implying that the loop may terminate and it  obscures that the get() 
is what is actually blocking).

Sorry for taking a while to evaluate this.  I looked at the effort you put in 
to the patch and wanted to really think it through.  This idea is inspired, but 
in the end I don't think it is a good fit for how people typically use the 
Queue module (or its cousin in the Multiprocessing module).

Do consider posting a queue variant to the Python Package Index.  Though not 
for all users, there may well be some uptake for a few users.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35034>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to