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
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
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
> 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
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).
>>
>>
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
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.
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
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: