This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients Martin.Teichmann, asvetlov, cjrh, yselivanov
Date 2019-11-21.19:43:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This seems like a useful idea. I recommend to write a test implementation and play with it.

> 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?

> 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.

> 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.
Date User Action Args
2019-11-21 19:43:03yselivanovsetrecipients: + yselivanov, asvetlov, cjrh, Martin.Teichmann
2019-11-21 19:43:02yselivanovsetmessageid: <>
2019-11-21 19:43:02yselivanovlinkissue37334 messages
2019-11-21 19:43:02yselivanovcreate