On 04.10.2016 13:30, Nick Coghlan wrote:
What it *doesn't* do, and what you need greenlet for, is making that
common interface look like you're using plain old synchronous C
threads.
If folks really want to do that, that's fine - they just need to add
gevent/greenlet as a dependency, just as the folks that don't like the
visibly object-oriented nature of the default unittest and logging
APIs will often opt for third party alternative APIs that share some
of the same underlying infrastructure.
Maybe, this is all a big misunderstanding.
asyncio is incompatible with regular execution flow and it's **always
blocking**. However, asyncio is perceived by some of us (including me)
as a shiny alternative to processes and threads but really isn't. I
remember doing this survey on python-ideas (results here:
https://srkunze.blogspot.de/2016/02/concurrency-in-python.html) but I
get the feeling that we still miss something.
My impression is that asyncio shall be used for something completely
different than dropping off things into a background worker. But looking
at the cooking example given by Steve Dower (cf. blog post), at other
explanations, at examples in the PEPs, it just seems to me that his
analogy could have been made with threads and processes as well.
At its core (the ASYNC part), asyncio is quite similar to threads and
processes. But its IO-part seem to drive some (design) decisions that
don't go well with the existing mental model of many developers. Even
PEP-reviewers are fooled by simple asyncio examples. Why? Because they
forget to spawn an eventloop. "async def and await" are just useless
without an eventloop. And maybe that's what's people frustration is
about. They want the ASYNC part without worrying about the IO part.
Furthermore, adding 2 (TWO) new keywords to a language has such an
immense impact. Especially when those people are told "the barrier for
new keywords is quite high!!". So, these new keywords must mean something.
I think what would help here are concrete answers to:
0) Is asyncio a niche feature only be used for better IO?
1) What is the right way of integrating asyncio into existing code?
2) How do we intend to solve the DRY-principle issue?
If the answer is "don't use asyncio", that's a fine result but honestly
I think it would be just insane to assume that we got all these
features, all this work and all those duplicated functions all for
nothing. I can't believe that. So, I am still looking for a reasonable
use-case of asyncio in our environment.
Cheers,
Sven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
