On 5/22/2018 5:21 AM, Ken Hilton wrote:

Hi all,

Just a simple idea I wanted to bring forth. Although I know that you get a lot more asyncio control by importing the asyncio module itself, I'd like to see a way to make simple asynchronous applications without ever importing asyncio itself. To that end, I propose making asyncio.get_event_loop() a builtin. This would enable simple things like this (example copied from websockets.readthedocs.io <http://websockets.readthedocs.io> with slight modifications):

    import websockets     async def hello():         async with websockets.connect('wss://echo.websocket.org <http://echo.websocket.org>') as ws:             amsg = 'a message'             print(f'> {amsg}')             await ws.send(amsg)             ret = await ws.recv()             print(f'< {ret}')     get_event_loop().run_until_complete(hello())

(Should that really be 'hello()' rather than 'hello'? I don't remember.) I like the idea of making coroutines easier and use. It would make more sense to me to expose an eventloop class as a builtin, so that one would write eventloop().run_until_complete(hello) eventloop would not necessarily have to be exactly the same as the default returned by get_event_loop. Would all the asyncio eventloop methods be needed? For running coroutines, it would be even nicer to write eventloop().run(hello) Eventloop could have an .__init__ method, or be a factory function, with a 'loop' parameter. The value specifies which eventloop implementation adaptor to use. The default might be 'asyncio', with alternatives such as 'uvloop', 'tkloop' (partly prototyped), 'twisted', and others. The adaptors should all have the same api: .run method that exits on completion, or a .run (forever) method paired with .stop. -- Terry Jan Reedy

On 5/22/2018 5:21 AM, Ken Hilton wrote:

Hi all,

Just a simple idea I wanted to bring forth. Although I know that you get a lot more asyncio control by importing the asyncio module itself, I'd like to see a way to make simple asynchronous applications without ever importing asyncio itself. To that end, I propose making asyncio.get_event_loop() a builtin. This would enable simple things like this (example copied from websockets.readthedocs.io <http://websockets.readthedocs.io> with slight modifications):

    import websockets     async def hello():         async with websockets.connect('wss://echo.websocket.org <http://echo.websocket.org>') as ws:             amsg = 'a message'             print(f'> {amsg}')             await ws.send(amsg)             ret = await ws.recv()             print(f'< {ret}')     get_event_loop().run_until_complete(hello())

(Should that really be 'hello()' rather than 'hello'? I don't remember.) I like the idea of making coroutines easier and use. It would make more sense to me to expose an eventloop class as a builtin, so that one would write eventloop().run_until_complete(hello) eventloop would not necessarily have to be exactly the same as the default returned by get_event_loop. Would all the asyncio eventloop methods be needed? For running coroutines, it would be even nicer to write eventloop().run(hello) Eventloop could have an .__init__ method, or be a factory function, with a 'loop' parameter. The value specifies which eventloop implementation adaptor to use. The default might be 'asyncio', with alternatives such as 'uvloop', 'tkloop' (partly prototyped), 'twisted', and others. The adaptors should all have the same api: .run method that exits on completion, or a .run (forever) method paired with .stop. -- Terry Jan Reedy