New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asyncio.Controller #74486
Comments
Over in https://github.com/aio-libs/aiosmtpd we have a Controller class which is very handy for testing and other cases. I realized that this isn't really aiosmtpd specific, and with just a few tweaks it could be appropriate for the stdlib. I have a branch ready for a pull request. This is the tracking/discussion issue. |
Looks interesting! What's the advantage over running the server and the test in the same loop? The ability to use blocking operations in the tests, and to re-use an expensive-to-start server over multiple tests? (I've mostly used threads in tests to run blocking code for interoperability testing, and kept the async code in the main thread, so this is a bit novel to me.) |
On May 08, 2017, at 11:06 PM, Nathaniel Smith wrote:
So, the ability to re-use expensive-to-start servers is definitely one of the As for running the server and tests in the same loop; I haven't tried that, One other use case I have is for the LMTP server in Mailman 3. The controller |
I'm not sure that Controller is generic enough to be part of asyncio. I'm not sure about the cancellation of all pending tasks on stop(). Why not starting by putting this class in a library to mature its API? |
On May 11, 2017, at 12:09 AM, STINNER Victor wrote:
It's already part of aiosmtpd although not with the small amount of |
I think the API is too specific. Instead of requiring hostname and port, why not let the user override setup and teardown coroutines? In your case, this could be: async def setup(self):
self.server = await self.loop.create_server(...)
async def teardown(self):
await self.server.wait_closed() |
Hi Antoine, On May 28, 2017, at 11:07 AM, Antoine Pitrou wrote:
Can you elaborate? What's too specific about it? Do you have in mind a use
It's certainly possible to factor those out so they could be overridden, I'm |
Any use case where setup is more elaborate than calling create_server(...). For example I might write a UDP server. Or a distributed system that listens to several ports at once, or launches a thread pool. etc. |
On May 29, 2017, at 07:07 AM, Antoine Pitrou wrote:
Thanks, those are nice motivational examples. |
I'm not sure we want this to be in asyncio: it's a very high-level object somewhere in between the low-level and the application level. Some things off the top of my head that users will want from this API:
Since asyncio is no longer provisional, it won't be possible to evolve the API in bugfix releases, which will likely make it impossible to use for many users until 3.8. In general, the advice for things like this is to put them on PyPI, gather some feedback, and sort out the API details. -1 to add this in 3.7 in its current state. P.S. It would be interesting to try to evolve the idea a bit further: it would be interesting if Controller was a high-level description of a service and we had a separate concept of ControllerRunner to run Controllers in threads, processes and corotuines. Maybe build something like erlang supervisor trees out of them. |
On May 29, 2017, at 11:42 PM, Yury Selivanov wrote:
There's also value in doing one simple thing that adds convenience for users. |
Barry: would you be ok to start by adding Controller to asyncio.test_utils, |
Sorry, but we are going to deprecate and remove test_utils soon. It's a bunch of internal unit test helpers used privately by asyncio. They are not documented and not supported. Now that asyncio repo is in CPython repo and we don't release it on its own, i see no reason to keep test_utils (we can move it to 'Lib/test'. Again, the natural way of something like Controller to end up in asyncio is to either go through full PEP process, or live some time on PyPI and prove to be useful. |
Yeah, I understand. I totally see how Controller can be useful, moreover, I'd be glad to assist you with the PEP though! |
On May 30, 2017, at 10:36 PM, Yury Selivanov wrote:
A PEP feels like overkill; we don't require PEPs for every addition to an I appreciate that you want to be careful not to saddle asyncio with too much |
Thing is, when asyncio was provisional, we still couldn't significantly IMHO: the design of Controller is currently incomplete (see one of my |
There doesn't seem to be much appetite for this in the stdlib, so closing. It'll just have to live in a third party module. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: