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

On Tue, Nov 8, 2016 at 3:11 PM, Martin Richard wrote: > The example I had in mind was a wrapper function creating a lock and > returning a coroutine instance. > I suppose we could change the Lock class (and other classes like it -- probably many) to look up the loop lazily, when first needed (i.

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 the only get_event_l

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 sleep1(): >> return Task(asyn

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

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 sleep1(): return Task(asyncio.sleep(1)) since both may be documented as being a "coroutine" but the latter r

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 forme

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 executed until processed by >

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 corouti

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

I think there's a whole new recommendation for library authors. They should just rely on get_event_loop() except under two circumstances: - When you need a loop but your loop is not yet running. Note that this should be very rare -- e.g. when you're calling a coroutine function like asyncio.sleep(

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

On Monday, October 31, 2016 at 9:49:48 PM UTC+1, Yury Selivanov wrote: > > > Awesome! I’ll reopen that PR in a couple of days. > > Thank you, > Yury Hi, now that the PR is merged, would like to update asynctest for python 3.6, and I'd like your advice about how get_event_loop() should now

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 guard against this in debug mod

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 > t

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 suggest different guidelines for libraries th

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 aiohttp (and other >

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 applicatio

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 lif