In jupyter / ipython, other repls, as well as from libraries,  asyncio code can be called.  To simplify integration, there should be a way for libraries to transparently do the right thing, call await or start a new global running event loop.  

This can be done without breaking the colored functions design constraint (only async can call async) and would not lead to dynamic coroutine architectures like gevent / lua.

The change would significantly reduce confusion that is pervasive in the python ecosystem and has lead to many people using a defacto approach of monkey patching (a monkey patch which only works on the surface).

Alternative, if this approach simply can not be accepted, better and more emphasized headline asyncio documentation would be appropriate to explain why the constraint is in place and the best patterns to use to work around the problem.   

It took me a lot of googling before I understood the reasoning of what is a very significant design choice.

There are many instances of this issue causing problems, but let me highlight this link:

https://github.com/ipython/ipykernel/issues/548#issuecomment-713637954

Note that the biggest problem are obviously repls, and there are quite a few (iPython has issues due to it's high coupling with jupyter).  Providing a contract for them will ensure consistent support across the ecosystem rather than a hodge podge of barely working hacks.


One solution, not meant to be prescriptive, is to provide a repl only API meant to execute at the top of the stack (from perspective of user) only.

I'm not sure what you're actually proposing, and only have a vague understanding of what you're complaining about. This is perhaps related to https://bugs.python.org/issue33523? If so then maybe leave a comment there?

asyncio code placed in a repl won't execute properly as it may (or may not) be running an event loop already.

This happens not just in traditional repls, but any platform that provides execution shells around code.  Other repls, Spyder, pyppeter, and a lot more.  Some of the maintainers reference running a monkey patch to fix the problem.

The link I provided referenced 40 complaints about this issue.

I am not really proposing anything, just that it be addressed by either new API or better documentation explaining how best to solve the problem.  I do provide an example of an idea.

But addressing is important.  Just leaving it up to the community is causing a lot of chaos, incompatibilities and bugs.   

Some are suggesting using get_event_loop() but you discourage using this api in the documentation.  Not sure what that guidance means exactly as it's not very clear under what constraints the API can be used and when it can't.

I guess what I'm saying, is you created a design problem with the sync can't call async constraint, but didn't suggest any solutions to solving it, and the solutions people are arriving at are pretty random.

btw, this is different than the other issue as I understand you don't want re-entrant calls to async.  Library integration can be done (painfully) by cherry picking the right API to call, but it's more painful with repls as that's not how they're used.

Blaze, I think this needs a concrete proposal: either a patch, or at least a formal example how the new API would be used.

Note that there's also async-sig mailing list that's less formal, as well as discuss.python.org to bounce ideas off others.

Ah, thanks.  Looked around for something like that but couldn't find it.  Will close this.