[Python-ideas] async objects

[Michel Desmoulin]

On the other hand, await / async is a fantastic interface to unify all 
concurrent paradigms and asyncio already provide a bridge with threads 
and subprocess. So it kinda make sense.

Le 04/10/2016 à 18:40, Sven R. Kunze a écrit :
> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/