[Python-ideas] Make asyncio.get_event_loop a builtin

[Terry 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