[Python-ideas] PEP 525: Asynchronous Generators

[Guido van Rossum]

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 <ncoghlan at gmail.com> wrote:

> On 9 August 2016 at 08:37, Sven R. Kunze <srkunze at mail.de> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160808/ac2c166b/attachment.html>