Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-27 Thread Nathaniel Smith
On Wed, Mar 27, 2019 at 1:49 PM Guido van Rossum wrote: > > On Wed, Mar 27, 2019 at 1:23 PM Nathaniel Smith wrote: >> >> On Wed, Mar 27, 2019 at 10:44 AM Daniel Nugent wrote: >> > >> > FWIW, the ayncio_run_encapsulated approach does not work with the >> > transport/protocol apis because the

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-27 Thread Daniel Nugent
FWIW, the ayncio_run_encapsulated approach does not work with the transport/protocol apis because the loop needs to stay alive concurrent with the connection in order for the awaitables to all be on the same loop. I think the notion that allowing an option for nested loops will inevitably lead

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Dima Tisnek
End-user point of view, a.k.a. my 2c: re more worrisome scenario: if "objects" from two event loops depends on each other, that's unsolvable in general case. On the other hand, what OP wanted, was akin to DAG-like functionality or locking hierarchy. Naive implementation would block caller

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Glyph
> As for jupyter, I think the best thing for them to do is run all notebook > user code in a separate thread dedicated to that purpose, and hide the fact > that the notebook itself is running asyncio as much as possible. That user > thread can start up its own event loop if it wants, but that's

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Guido van Rossum
On Mon, Mar 25, 2019 at 5:11 PM Ben Darnell wrote: > On Mon, Mar 25, 2019 at 8:02 PM Guido van Rossum wrote: > >> >> Given PBP, I wonder if we should just relent and have a configurable flag >> (off by default) to allow nested loop invocations (both the same loop and a >> different loop). >> >>

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Ben Darnell
On Mon, Mar 25, 2019 at 8:02 PM Guido van Rossum wrote: > > Given PBP, I wonder if we should just relent and have a configurable flag > (off by default) to allow nested loop invocations (both the same loop and a > different loop). > > Allowing reentrant calls to the same loop is not a good idea

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Guido van Rossum
On Mon, Mar 25, 2019 at 4:54 PM Ben Darnell wrote: > On Mon, Mar 25, 2019 at 7:37 PM Guido van Rossum wrote: > >> Thanks for bringing this up -- I think it will be good to get to the >> bottom of this, before the Jupyter folks accidentally get everyone to use >> an approach that is unsound.

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-25 Thread Guido van Rossum
Thanks for bringing this up -- I think it will be good to get to the bottom of this, before the Jupyter folks accidentally get everyone to use an approach that is unsound. Maybe they can be redirected to a better strategy, or maybe they can convince us to change asyncio: it's totally possible that

[Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

2019-03-22 Thread Daniel Nugent
Hello, I was hoping that the Async SIG might have some suggestions on how to deal with this sort of issue: More frameworks are adopting asyncio as time marches on. A notable example of this is Jupyter and the Python kernels it supports (please see announcement here: