Re: [python-tulip] Explicit vs Implicit event loop

2016-11-08 22:00 GMT+01:00 Guido van Rossum : > But they could also call it before a loop is active and then call > run_until_complete() on the thing. E.g. > > f = sleep1() # definition from my previous post > asyncio.get_event_loop().run_until_complete(f) > > Assuming that's

Re: [python-tulip] Explicit vs Implicit event loop

On Tue, Nov 8, 2016 at 12:43 PM, Yury Selivanov wrote: > > > On 2016-11-08 3:29 PM, Guido van Rossum wrote: > >> I think the problem is that it's hard to tell the difference between these >> two: >> >> async def sleep1(): >> await asyncio.sleep(1) >> >> def

Re: [python-tulip] Explicit vs Implicit event loop

I think the problem is that it's hard to tell the difference between these two: async def sleep1(): await asyncio.sleep(1) def sleep1(): return Task(asyncio.sleep(1)) since both may be documented as being a "coroutine" but the latter references the loop when you calls it, while the

Re: [python-tulip] Explicit vs Implicit event loop

Martin, > On Nov 8, 2016, at 1:39 PM, Martin Richard wrote: > > I fully agree about coroutines, one thing though: I often see functions > returning awaitables documented as "coroutines", and I see that as a problem > since it gives the assumption that it won't be

Re: [python-tulip] Explicit vs Implicit event loop

I fully agree about coroutines, one thing though: I often see functions returning awaitables documented as "coroutines", and I see that as a problem since it gives the assumption that it won't be executed until processed by the loop. For instance, asynctest can't identify them as coroutines, they

Re: [python-tulip] Explicit vs Implicit event loop

On 2016-11-08 11:07 AM, Martin Richard wrote: - the feature is left as it is: a library author should no longer have to deal with the loop from a coroutine/a callback, and this is how asyncio libraries should be written. ^- this. To add to what Guido said, I think we should promote

Re: [python-tulip] Explicit vs Implicit event loop

On Tuesday, November 1, 2016 at 6:46:12 PM UTC+1, Andrew Svetlov wrote: > The same problem is present in asyncio classes itself: Lock, Queue, > streams could be created with global life time and they are will hang if > used from different loop. > Since PR #303

Re: [python-tulip] Explicit vs Implicit event loop

> On Nov 1, 2016, at 10:46 AM, Andrew Svetlov wrote: > > The same problem is present in asyncio classes itself: Lock, Queue, streams > could be created with global life time and they are will hang if used from > different loop. Once we fix get_event_loop we can

Re: [python-tulip] Explicit vs Implicit event loop

On Monday, October 31, 2016 at 6:27:57 PM UTC+2, Guido van Rossum wrote: > > It's an interesting problem. I would like to rephrase your conclusion: > the implicit loop should only be used when the object you are creating > has a shorter (or equal) lifetime than the loop. I would also think >

Re: [python-tulip] Explicit vs Implicit event loop

> On Oct 31, 2016, at 2:43 PM, Guido van Rossum wrote: > > Thanks! We can fix this in 3.6b4. Awesome! I’ll reopen that PR in a couple of days. Thank you, Yury

Re: [python-tulip] Explicit vs Implicit event loop

On Mon, Oct 31, 2016 at 1:30 PM, Yury Selivanov wrote: > Guido, > > I’m with Andrew on this one. > And the reason is the misbehavior of get_event_loop(), right? (See below.) > > On Oct 31, 2016, at 10:27 AM, Guido van Rossum wrote: > > > > I would

Re: [python-tulip] Explicit vs Implicit event loop

Guido, I’m with Andrew on this one. > On Oct 31, 2016, at 10:27 AM, Guido van Rossum wrote: > > I would suggest different guidelines for libraries than for > applications: Libraries should be robust and always store their own > loop. This is how asyncio itself works and how

Re: [python-tulip] Explicit vs Implicit event loop

Hi, Indeed, for applications, I believe that we should rather depend on defining the right EventLoopPolicy (or use the default one if most cases) and call get_event_loop() when required rather than passing the loop explicitly. Most of the time a policy is sufficient to describe how your

Re: [python-tulip] Explicit vs Implicit event loop

It's an interesting problem. I would like to rephrase your conclusion: the implicit loop should only be used when the object you are creating has a shorter (or equal) lifetime than the loop. I would also think that the real problem with the code example is that it creates a variable with global