<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 6:22 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">Wolfgang,<div><div class="h5"><br>
<br>
On 2015-04-23 12:12 PM, 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 5:32 PM, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Wolfgang,<br>
<br>
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:<br>
<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>><br>
wrote:<br>
<br>
Hello,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
3.<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">
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>
<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>
<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>
I don't think it is bad nor not needed, but the syntax is not beautiful<br>
</blockquote>
and<br>
for the 90% not doing async stuff irritating and one more thing to learn<br>
and do right/wrong.<br>
<br>
</blockquote>
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>
</blockquote>
Don't mean it can be done wrong on execution or syntax level.<br>
I mean for a beginner it is not as easy an more and some will try<br>
async in some places, yes they will get an error. But there is a<br>
new possibility to get such errors if async is there for with and for<br>
statements.<br>
And the next beginner will then implement __aiter__ instead of __iter__<br>
because<br>
he/she don't get it.<br>
</blockquote>
<br></div></div>
Sorry, Wolfgang, but I don't get your argument. Beginners<br>
shouldn't just randomly try to use statements. There is a<br>
documentation for that. Plus we can make exception messages<br>
better.<span class=""><br></span></blockquote><div><br></div><div>Had to coach a lot of new users to Python and some to async stuff in twisted.<br></div><div>And what beginners not should do don't care them. ;-)<br></div><div>They will do strange stuff and go other way's than you expected. I only like to make<br></div><div>it as easy as possible for them. Nothing more.<br></div><div>Less keywords, less ways to do something, best only one way to do it.<br></div><div><br><br><br></div><div>Don't get me wrong, I like the PEP it is well written and covers a lot of areas about async programming.<br></div><div>I know Python must improve in this area and has a lot of potential.<br></div><div>But don't hesitate, give the people time to try it and mature it. If all this should be in 3.5 it is to early.<br><br></div><div>Also we can avoid the async keyword completely and do the same as for generators.<br></div><div>If there is an await, it is a coroutine.<br></div><div>IDE's can detect generators and must only be expanded to detect coroutines.<br></div><div><br></div><div>Function<br></div><div>with yield -> return a generator<br></div><div>with await -> return a coroutine<br><br></div><div>Move async for and async with to another PEP and handle it later or with a different syntax using the new await keyword.<br><br></div><div>Only one new keyword, good improvement for async programming.<br><br></div><div>Sorry still don't like the word async in a language and sprinkle it every where.<br></div><div>And still have the feeling if we provide async for loop we next must provide async like generator expresions or list comprehensions or ...<br></div><div>never ends ;-)<br><br></div><div>The only downside with await converting a function to a coroutine is, it is not explicit marked.<br></div><div>But if we care about this, whats about generators and yield ?<br></div><div> </div><br></div>-- <br><div class="gmail_signature">bye by Wolfgang</div>
</div></div>