[Python-ideas] PEP 525: Asynchronous Generators

[Sven R. Kunze]

On 09.08.2016 05:23, Nick Coghlan wrote:
> On 9 August 2016 at 08:37, Sven R. Kunze <srkunze at mail.de 
> <mailto: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/


If it's a such well-known **problem**, why does it even exist in Python 
in the first place? ;-)

I don't buy that one couldn't have avoided it.


Lately, I talked to friend of mine about async and his initial reaction 
was like "hmm that reminds me of early programming days, where you have 
to explicitly tell the scheduler to get control back". He's much older 
than me, so I think it was interesting for him to see that history is 
repeating again.


> 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/

Interesting shift indeed and I like small Lego bricks I can use to build 
a big house.

However, couldn't this be achieved without splitting the community?


Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160810/51381f70/attachment.html>