RetroSearch Browse

Thu Apr 23 17:32:33 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-April/139453.html

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.

> 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#.

Yury

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/139453.html below:

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