[Python-Dev] PEP 492: async/await in Python; version 4

tds333 at gmail.com tds333 at gmail.com
Tue May 5 09:54:35 CEST 2015


Hi,

still watching progress here. Read all posts and changes.

Everything improved and I know it is a lot of work. Thx for doing this.

But I still think this PEP goes to far.

1. To have "native coroutines" and await, __await__ is very good and
useful. Also for beginners to see and mark coroutines are a different
concept than generators. Also this is easy to learn. Easier as to
explain why a generator is in this case a coroutine and so on.

2. I still don't like to sprinkle async everywhere. At all we don't need
it for the first step.
We can handle coroutines similar to generators, when there is a await in
it then it is one. Same as for yield. Or to be more explicit, if it is
marked as one with @coroutine it is enough. But then it makes also sense
to do the same for generators with @generator. We should be consistent here.

3. async with is not needed, there are rare use cases for it and every
can be written with a try: except: finally:
Every async framework lived without it over years. No problem because
for the seldom need try: ... was enough.

4. async for can be implemented with a while loop. For me this is even
more explicit and clear. Every time I see the async for I try to find
out what is done in async manner. For what I do an implicit await ?
Also in most of my uses cases it was enough to produce Futures in a
normal loop and yield (await) for them.
Even for database interfaces. Most of the time they do prefetching under
the hood and I don't have to care at all.

5. For async with/for a lot of new special methods are needed all only
prefixed with "a". Easy to confuse with "a" for abstract. Often used
to prefix abstract classes. Still think __async_iter__, __async_enter__
is better for this. Yes more to write but not so easy to confuse with
the sync __iter__ or __enter__, ... And matches more to I must use async
to call them.


I am not new to the async land, have done a lot of stuff with twisted
and even looked at tornado.
Also has tried to teach some people the asnc world. This is not easy
and you learn most only by doing and using it.

For my final conclusion, we should not rush all this into the language.
Do it step by step and also help other Python implementations to support
it. For now only a very low percentage are at Python 3.4.
And if you compare the statistics in PyPi, you see most are still at
Python 2.7 and using async frameworks like twisted/tornado.
We do such a fundamental language change only because a few people need
it for a niche in the whole Python universe?
We confuse the rest with new stuff they never need?

Even the discussion on python-dev suggests there is some time needed
to finalize all this.

We forget to address the major problems here. How can someone in a
"sync" script use this async stuff easy. How can async and sync stuff
cooperate and we don't need to rewrite the world for async stuff.
How can a normal user access the power of async stuff without rewriting
all his code. So he can use a simple asyc request library in his code.
How can a normal user learn and use all this in an easy way.

And for all this we still can't tell them "oh the async stuff solves
the multiprocessing problem of Python learn it and switch to version
3.5". It does not and it is only most useful for networking stuff
nothing more.

Don't get me wrong, I like async programming and I think it is very
useful. But had to learn not everyone thinks so and most only want
to solve there problems in an easy way and not get a new one called
"async".


Now I shut up. Go to my normal mode and be quiet and read. ;-)



Regards,

Wolfgang







More information about the Python-Dev mailing list