On Sun, Jun 14, 2020 at 10:38 PM J. Pic wrote:
>
> Well correct me if I'm wrong (I did a bit of homework), but threads are hard
> to get right because they may switch at any time.
>
> When we do async instead of threads, it's because we want task switch on
> blocking operations only.
>
That's a
> This proposal would elevate it to a very special status,
making it effectively part of the language rather than just a module
in the stdlib.
Indeed, thank you Greg for the clarification
___
Python-ideas mailing list -- python-ideas@python.org
To unsubs
Well correct me if I'm wrong (I did a bit of homework), but threads are
hard to get right because they may switch at any time.
When we do async instead of threads, it's because we want task switch on
blocking operations only.
The thing that is still not quite clear to me, and really I must apolog
On 13/06/20 8:47 am, J. Pic wrote:
Why not make using await do asyncio.run "behind the scenes" when called
outside async function ?
That would directly tie the await syntax to the asyncio module. This
would not be a good idea. Currently there is nothing special about
asyncio -- it's just one of
> Do you mean that it's not possible to implement this at the syntax level
> because we don't know until runtime if this is being call from a loop (async
> calling sync code) ?
No. I'm saying you should clarify the semantics you want if you have
if your sync `test()` is called from within an asy
> I do think there is some case for non rentrency and nested loop where
what you define here would block an outer loop, but most people
suggesting what you ask actually want re-entrency, which is not
possible there.
Do you mean that it's not possible to implement this at the syntax level
because w
See some of the previous discussions on asyncio reentrancy.
https://mail.python.org/pipermail/async-sig/2019-March/thread.html
I do think there is some case for non rentrency and nested loop where
what you define here would block an outer loop, but most people
suggesting what you ask actually wan
