Yury Selivanov <yseliva...@gmail.com> added the comment:
This seems like a useful idea. I recommend to write a test implementation and play with it. Andrew: > I think the proposal makes the queues API more error-prone: concurrent put() > and close() produces unpredictable result on get() side. How? Can you elaborate? Caleb: > I'm interested in how this change would affect the pattern of shutting down a > queue-processing task. Agree, this can be useful for that. Martin: > Given the reactions I gather "close" is a better name for the method, so I > changed it accordingly. Not sure I like "close" since it will *cancel* all getters and putters & discard all items in the queue AND allow further operation on the queue. The latter part is really questionable -- what's the point of losing the data in the queue and resuming it? Seems like a mechanism for writing unreliable code, but perhaps you can give us an example where this is necessary. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37334> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
