Wolfgang,
On 2015-04-23 12:58 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov <yselivanov...@gmail.com>
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov <yselivanov...@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 <pmis...@gmail.com>
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov <andrew.svet...@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.
Don't mean it can be done wrong on execution or syntax level.
I mean for a beginner it is not as easy an more and some will try
async in some places, yes they will get an error. But there is a
new possibility to get such errors if async is there for with and for
statements.
And the next beginner will then implement __aiter__ instead of __iter__
because
he/she don't get it.
Sorry, Wolfgang, but I don't get your argument. Beginners
shouldn't just randomly try to use statements. There is a
documentation for that. Plus we can make exception messages
better.
Had to coach a lot of new users to Python and some to async stuff in
twisted.
And what beginners not should do don't care them. ;-)
They will do strange stuff and go other way's than you expected. I only
like to make
it as easy as possible for them. Nothing more.
Less keywords, less ways to do something, best only one way to do it.
Don't get me wrong, I like the PEP it is well written and covers a lot of
areas about async programming.
I know Python must improve in this area and has a lot of potential.
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.
The thing about this PEP is that it's build on existing
concepts that were validated with asyncio.
As for is it enough time to review it or not -- it's up to
BDFL to decide. I'm doing my best trying to get the reference
implementation reviewed and to address all questions in the
PEP, hoping that it will help.
I can only say that if it doesn't land in 3.5, we'll have
to wait another *1.5 years*. And it's not that people will
download CPython 3.6.alpha0 and start rewriting their code
and playing with it. In the meanwhile, people want more
good reasons to migrate to Python 3, and I strongly believe
that this PEP is a great reason.
Moreover, it's several months before 3.5 is released. We still
will be able to slightly alter the behaviour and gather
feedback during beta periods.
Also we can avoid the async keyword completely and do the same as for
generators.
If there is an await, it is a coroutine.
Unfortunately there is a problem with this approach:
refactoring of code becomes much harder. That's one of the
corner cases that @coroutine decorator solves; see
https://www.python.org/dev/peps/pep-0492/#importance-of-async-keyword
Thanks,
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
