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