Adding Cycle Buffer to asyncio.Queue

Hey, all!

I’ve filed an issue on BPO in May:

It looks handy to be able to leverage collections.deque ability to be sized in asyncio.Queue.

This could provide the ability to implement backpressure in a queue or just use it as a buffer in messaging systems.

And I even implemented this. Here is the PR: https://github.com/python/cpython/pull/20071

What do you think?

I see that the attached issue and PR is closed now, but just to provide some feedback:

Personally, looking at the implementation, I don’t see enough unique functionality to justify a separate class in asyncio or within stdlib in general (as opposed to something that could just be implemented locally and written about as a recipe idea). Also, in the BPO issue itself, I don’t think there was a strong enough argument justifying the value of having this asyncio.BufferQueue in the standard library. It’s good to have more detailed accounts of how yourself and others would specifically use the feature rather than a couple generalized sentences about how it might be used. Essentially, the goal is to convince others that it would definitely be used enough to justify stdlib inclusion, which is quite a high bar.

For future reference to save yourself from putting forth the effort to implement without having any results, I would recommend initially proposing the idea on somewhere like python-ideas, python-list, or within the discuss ideas section, and then opening a bpo issue without a PR attached. Then, if one of the asyncio maintainers (such as Yury or Andrew) shows interest in the idea (or just several from the community explaining why they’d like the feature), you can proceed with opening a PR. This is the general process that occurs when adding an entirely new member that doesn’t have an existing open issue associated with it.

It’s not specifically required to put together this formal proposal and wait on a core dev to approve of the idea first, but generally, you do want to spend some time assessing what the core development community thinks of the idea prior to opening a PR with implementation, tests, and docs. Without any significant assessment beforehand, there’s a much greater chance of it being rejected and/or not getting as much attention.

(Also, for future reference, I’d suggest leaving the bpo issue and PR open longer. There’s not really an upper bound time limit on when an issue/PR is too old to respond to, and it’s quite common for us core devs to go back and work through issues that are as old as several years when we find the time to do so.)

I would like to also thank you for your effort though and apologize for the delayed response. If you have an interest in working on something else, I would advise looking at existing open issues (those generally result in quicker responses and a higher likelihood of your implementation being included, compared to opening a new issue and opening a PR before the idea is approved).

1 Like