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 Martin.Teichmann
Recipients Martin.Teichmann, asvetlov, cjrh, yselivanov
Date 2019-11-22.11:49:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574423360.99.0.509899222443.issue37334@roundup.psfhosted.org>
In-reply-to
Content
Hi Andrew,

I still don't get your point. First, this is an extension to the asyncio library, so concurrency is not an issue. And sure, if you call random methods of an object without any reason the outcome won't be anything useful, why, in your example, should the one task call close at all?

There is, however, a strong use case: If you have many producers but just one consumer and the consumer stops consuming, it should cancel all producers waiting on the queue. The same way, if you have one producer but many consumers, once the single producer stops producing, it should cancel all waiting consumers. In these situations, the outcome is very clear.

Whether it should be possible to "resurrect" a closed/cancelled queue I don't care much, as I neither see a use case in doing so nor a compelling argument why it should be artificially prohibited. So I simply went for the most simple code.

The proposed code does something very simple, something a user can grasp. That is IMHO a better protection for users than some code trying to artificially stop users from harming themselves.
History
Date User Action Args
2019-11-22 11:49:21Martin.Teichmannsetrecipients: + Martin.Teichmann, asvetlov, cjrh, yselivanov
2019-11-22 11:49:20Martin.Teichmannsetmessageid: <1574423360.99.0.509899222443.issue37334@roundup.psfhosted.org>
2019-11-22 11:49:20Martin.Teichmannlinkissue37334 messages
2019-11-22 11:49:20Martin.Teichmanncreate