On Sep 11, 2014, at 6:42, Martin Teichmann
Hi List,
I'm currently trying to convince my company that asyncio is a great thing. After a lot of critique, the newest thing is, people complain: I cannot test my code on the command line! And indeed they are right, a simple
a = yield from some_coroutine()
is not possible on the command line, and doesn't make sense.
Wait a minute, really?
Well, it could make sense, in an asyncio-based command line. I am thinking about a python interpreter whose internal loop is something like
@coroutine def commandline(): while True: cmd = yield from input_async() code = compile(cmd, "<stdin>", "generator") yield from exec(code)
I would love to see this. I'm not sure if I'd love it in practice or not, but until someone implements it and I can play with it I'm not sure how I'd become sure. So... You just volunteered, right? Go build it and put it on PyPI, I want it and I'll be your best friend forever and ever no takebacks if you do it. :)
A new compile mode would allow to directly, always create a generator, and exec should be certainly be able to handle this.
I think this would not only make people happy that want to test code on the command line, but also all those people developing command line-GUI combinations (IPython comes to mind), which have to keep several event loops in sync.
If it also came with builtin wrappers to embed all the popular GUI event loops in asyncio-style coroutines (or, hell, I'd be happy with just Tkinter, or the native Cocoa runloop) and automatically toss them into the main event loop, that could make interactively experimenting with GUIs as easy as it is in Smalltalk (well, except for not being able to turn your experiment into a persistent image). But that one seems like more work than just making the command prompt event-driven and coro-friendly.