[Python-Dev] async/await in Python; v2

[Yury Selivanov]

Hi Wolfgang,

On 2015-04-23 11:57 AM, Wolfgang Langner wrote:
> On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
>
>> Hi Wolfgang,
>>
>> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>>
>>> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky <pmiscml at gmail.com>
>>> wrote:
>>>
>>>   Hello,
>>>> On Thu, 23 Apr 2015 12:18:51 +0300
>>>> Andrew Svetlov <andrew.svetlov at gmail.com> wrote:
>>>>
>>>> []
>>>>
>>>>   3.
>>>>>> async with and async for
>>>>>> Bead idea, we clutter the language even more and it is one more
>>>>>> thing every newbie could do wrong.
>>>>>> for x in y:
>>>>>>     result = await f()
>>>>>> is enough, every 'async' framework lived without it over years.
>>>>>>
>>>>> async for i in iterable:
>>>>>       pass
>>>>>
>>>>> is not equal for
>>>>>
>>>>> for fut in iterable:
>>>>>       i = yield from fut
>>>>>
>>>> But people who used Twisted all their life don't know that! They just
>>>> know that "async for" is not needed and bad.
>>>>
>>>>
>>>>   I don't think it is bad nor not needed, but the syntax is not beautiful
>>> and
>>> for the 90% not doing async stuff irritating and one more thing to learn
>>> and do right/wrong.
>>>
>> There is no way to do things wrong in PEP 492.  An object
>> either has __aiter__ or it will be rejected by async for.
>> An object either has __aenter__ or it will be rejected by
>> async with.
>>
>>    transaction = yield from connection.transaction()
>>    try:
>>      ...
>>    except:
>>      yield from transaction.rollback()
>>    else:
>>      yield from transaction.commit()
>>
>> is certainly more irritating than
>>
>>    async with connection.transcation():
>>      ...
>>
>>
>>> I had also a need for async loop. But there are other solutions like
>>> channels,
>>> not needing a new syntax.
>>>
>>> Also possible a function returning futures and yield in the loop with a
>>> sentinel.
>>>
>>> All this goes the road down to a producer consumer pattern. Nothing more.
>>>
>>>
>>>
>>>   I know I'm a bad guy to make such comments, too bad there's a bit of
>>>> truth in them, or everyone would just call me an a%$&ole right away.
>>>>
>>>>
>>>> Generally, I already provided feedback (on asyncio list) that asyncio
>>>> is based not on native Python concepts like a coroutine, but on
>>>> foreign concurrency concepts like callback or Future, and a coroutine
>>>> is fitted as a second-class citizen on top of that. I understand why
>>>> that was done - to not leave out all those twisteds from a shiny new
>>>> world of asyncio, but sometimes one may wonder if having a clear cut
>>>> would've helped (compat could then have been added as a clearly separate
>>>> subpackage, implemented in terms of coroutines). Now people coming from
>>>> non-coroutine frameworks who were promised compatibility see "bad"
>>>> things in asyncio (and related areas), and people lured by a promise of
>>>> native Python framework see bad things too.
>>>>
>>>>
>>>>   This has nothing to do with people using twisted or other async
>>> frameworks
>>> like tornado.
>>> I think a coroutine should be first class. But all this should be done in
>>> a
>>> way a beginner
>>> can handle and not design this stuff for experts only.
>>>
>> I think that most of async frameworks out there are for
>> experts only.  Precisely because of 'yield from', 'yield',
>> inlineCallbacks, '@coroutine', channels and other stuff.
>>
>> PEP 492 will make it all easier. And Twisted can use
>> its features too.
>>
> Yes and it is good to make it easier. But not complicate it for others.
> Beginners will be confronted with all this new syntax an my feel lost.
> Oh I have to different for loops, one with async. Same for with statement.

Absolute beginners don't write async code and http servers.

And when they start doing things like that, they're not someone
who can't understand 'async' and 'await'.  It's not harder
than '@coroutine' and 'yield from'.

What is hard for even experienced users, is to understand
what's the difference between 'yield from' and 'yield', and
how asyncio works in the core. Why you should always use the
former etc.

Unfortunately I just can't agree with you here.  Too much time
was spent trying to explain people how to write asyncio code,
and it's hard.  PEP 492 will make it easier.

>
>
>>   If we do this we
>>> scare away new people.
>>>
>> It doesn't scare away anyone.  async/await were the most
>> awaited features in dart and javascript.  One of the most
>> popular features in c#.
>>
> I like it in C#.
> I like await for Python but I don't like async there and how to specify it.
> I still think a decorator is enough and no special for and with syntax.
Please read the "Debugging Features" section in the PEP. It explains
why decorator is not enough.  Also the "Rationale" section also
stresses some points.

Decorator solution is "enough", but it's far from being ideal.

For IDEs and linters it's harder to support.  What if you
write "from asyncio import coroutine as coro"?  You have to analyze
the code statically to reason about what "@coroutine" is.  Moreover,
you need to enable good IDE support for other frameworks too.

>
> async in JavaScript is for execution a whole script asynchronously used in
> the script tag.
> dart is for the google universe with less usage outside.
>
>

Please read a proposal to add async/await in JS (refd in the PEP).
It's very likely to be accepted, because JS is asynchronous to its
very core, and it's a pain to program in it with callbacks.

yields in JS will mitigate the problem but not completely, so
it's only matter of time.  In the PEP there is a good list of
other languages with async/await.

Thank you,
Yury