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

[python-tulip] Announcing Motor 1.0, async driver for MongoDB

On November 2nd, I released the first API-stable release of Motor, the asynchronous Python driver for MongoDB. Motor can integrate with either Tornado or asyncio. It is compatible with Python 2.6 or later and all supported versions of MongoDB. Motor 1.0 requires PyMongo 3.3 or newer. The move

Re: [python-tulip] Re: [tornado] Re: Announcing Motor 0.7, async MongoDB driver for Tornado and asyncio

Sorry I forgot to email the list about Motor 1.0! I'll do that. On Tuesday, November 8, 2016 at 8:54:45 AM UTC-5, Gregoire Piffault wrote: > > I'm glad you took the thread pool approach, supporting latest pymongo > should be simpler now. > For those who missed it as I did, 1.0 has been released

Re: [python-tulip] inspect.iscoroutine only works for "native" coros

Reading into these flags more, I wonder if modifications to the inspect.iscoroutine* functions as well as to genobject.c's finalizer are justified. Specifically to check for both CO_ITERABLE_COROUTINE and CO_COROUTINE in any place where a coroutine is expected. Note that this is an inversion of