Raymond Hettinger added the comment: Here's a link to the feature request for Ruby, https://bugs.ruby-lang.org/issues/10600 . It looks like the feature was implemented without examining any concrete use cases. A quick code search on Github did not reveal any cases where the feature was ever used after it was added to Ruby.
For now, I think we should pass on this one. Python's GIL limits what people typically do with threads (use cases focus on I/O bound tasks instead of CPU bound). Consequently, it is atypical to have a multi-producer-multi-consumer use case, and it would be even more rare for that case to also need the queue to inform all the consumers to shutdown (pure daemons are the norm). In addition, we already have work-arounds for those cases (shared variables, multiple poison-pills, secondary command queues, timeouts, etc). The single consumer example in the standard library is already satisfactorily handled using None as a sentinel. AFAICT, that code would not read any better with the new API. The library itself is not typically a good indicator of end-user need (our needs tend to be more exotic). The queue module has had a long life and this feature request hasn't arisen before, so that may indicate that this isn't a recurring or prevalent need. It seems that what the OP really wants is for this feature to be implemented in asyncio. I don't have much of an opinion on that one. It seems to me that in a single-thread-single-process there isn't any benefit that would come from having multiple consumers, so I'm not sure why someone would need this feature (passing in None for a single consumer is already simple and doesn't require API expansion). Without a recurring need, I think it is better not to do this one because the negatives would outweigh the positives. It would open the door to a requests for is_closed(), for a closing context manager, and for a way to re-open a closed queue. This request would make more sense in a distributed or multi-processing environment (where multiple consumers have real benefits), but for plain threads, where it may be more distracting than helpful. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29701> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
