[Python-ideas] PEP 525: Asynchronous Generators

[Nick Coghlan]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160809/887c7b26/attachment.html>