Just don't oversell run_until_complete() -- some people coming from slightly different event loop paradigms expect to be able to pump for events at any point, possibly causing recursive invocations. That doesn't work here (and it's a feature it doesn't).
On Mon, Aug 8, 2016 at 8:23 PM, Nick Coghlan <[email protected]> wrote: > On 9 August 2016 at 08:37, Sven R. Kunze <[email protected]> wrote: > >> From what I've heard in the wild, that most if not all pieces of async >> are mirroring existing Python features. So, building async basically builds >> a parallel structure in Python resembling Python. Async generators complete >> the picture. Some people (including me) are concerned by this because they >> feel that having two "almost the same pieces" is not necessarily a good >> thing to have. And not necessarily bad but it feels like duplicating code >> all over the place especially as existing functions are incompatible with >> async. >> > > It's a known problem that applies to programming language design in > general rather than being Python specific: http://journal.stuffwithstuff. > com/2015/02/01/what-color-is-your-function/ > > The async/await model used in C# and Python 3.5+ aims to at least make it > clear whether you're dealing with "red" (asynchronous) or "blue" > (synchronous) code, but some use cases will still benefit from using > something like gevent to bridge between the synchronous world and the > asynchronous one: http://python-notes.curiousefficiency.org/en/ > latest/pep_ideas/async_programming.html#gevent-and-pep-3156 > > In cases where blocking for IO is acceptable, the "run_until_complete()" > method on event loop implementations can be used in order to invoke > asynchronous code synchronously: http://www.curiousefficiency. > org/posts/2015/07/asyncio-background-calls.html > > >> As I understand it, one goal is to be as close to sync code as possible >> to make async code easier to understand. So, if dropping 'await's all over >> the place is the main difference between current async and sync code, I get >> the feeling both styles could be very much unified. (The examples of the >> PEP try to do it like this but it wouldn't work as we already discussed.) >> Maybe, it's too early for a discussion about this but I wanted to dump this >> thought somewhere. :) >> > > One of the big mindset shifts it encourages is to design as many support > libraries as possible as computational pipelines and message-drive state > machines, rather than coupling them directly to IO operations (which is the > way many of them work today). Brett Cannon started the Sans IO information > project to discuss this concept at http://sans-io.readthedocs.io/ > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
