[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: 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. -- resolution: -> wont fix stage: -> resolved status: open -> closed

[issue30300] asyncio.Controller

Yury Selivanov added the comment: > I appreciate that you want to be careful not to saddle asyncio with too much > baggage, or that you don't feel Controller is significant enough to generalize > and put in the package. Perhaps a middle ground would be to label parts of > the asyncio API

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: On May 30, 2017, at 10:36 PM, Yury Selivanov wrote: >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. A PEP feels like overkill; we don't

[issue30300] asyncio.Controller

Yury Selivanov added the comment: > There's also value in doing one simple thing that adds convenience for users. > I don't personally have any interest in building something as elaborate as the > above, but I've used the simple idea here several times in different projects. Yeah, I understand.

[issue30300] asyncio.Controller

Yury Selivanov added the comment: > STINNER Victor added the comment: > > Barry: would you be ok to start by adding Controller to asyncio.test_utils, > and wait later to expose it in the public API? Sorry, but we are going to deprecate and remove test_utils soon. It's a bunch of internal unit

[issue30300] asyncio.Controller

STINNER Victor added the comment: Barry: would you be ok to start by adding Controller to asyncio.test_utils, and wait later to expose it in the public API? -- ___ Python tracker

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: On May 29, 2017, at 11:42 PM, Yury Selivanov wrote: >- detailed logging or hooks to implement it >- hooks on thread start / stop >- coroutines to run before starting the server >- coroutines to run before stopping the loop >- custom undhandled exceptions

[issue30300] asyncio.Controller

Yury Selivanov added the comment: 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: - detailed logging or hooks to implement it - hooks

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: On May 29, 2017, at 07:07 AM, Antoine Pitrou wrote: >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. Thanks, those are nice motivational examples. --

[issue30300] asyncio.Controller

Antoine Pitrou added the comment: > Can you elaborate? What's too specific about it? Do you have in mind a use > case where you wouldn't need to provide hostname and port? Any use case where setup is more elaborate than calling create_server(...). For example I might write a UDP server.

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: Hi Antoine, On May 28, 2017, at 11:07 AM, Antoine Pitrou wrote: >I think the API is too specific. Can you elaborate? What's too specific about it? Do you have in mind a use case where you wouldn't need to provide hostname and port? >Instead of requiring

[issue30300] asyncio.Controller

Antoine Pitrou added the comment: 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

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: On May 11, 2017, at 12:09 AM, STINNER Victor wrote: >Why not starting by putting this class in a library to mature its API? It's already part of aiosmtpd although not with the small amount of generic-ness included here. It's been useful and stable. So this

[issue30300] asyncio.Controller

STINNER Victor added the comment: 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? -- nosy: +haypo

[issue30300] asyncio.Controller

Barry A. Warsaw added the comment: On May 08, 2017, at 11:06 PM, Nathaniel Smith wrote: >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

[issue30300] asyncio.Controller

Nathaniel Smith added the comment: 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

[issue30300] asyncio.Controller

Changes by Barry A. Warsaw : -- pull_requests: +1594 ___ Python tracker ___ ___

[issue30300] asyncio.Controller

New submission from Barry A. Warsaw: 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