On 15 November 2016 at 04:39, Yury Selivanov wrote:
> On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
>>
>> What about making "run" an instance method of coroutines?
>
> That would require coroutines to be aware of the loop that is running them.
> Not having them aware of that is what makes the design
What about making "run" an instance method of coroutines?
On 14.11.2016 19:30, Yury Selivanov wrote:
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which
would be
something akin to
def run(coro):
return get_event_loo
On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
What about making "run" an instance method of coroutines?
That would require coroutines to be aware of the loop that is running
them. Not having them aware of that is what makes the design simple and
allows alternatives to asyncio.
All in all
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which would be
something akin to
def run(coro):
return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Please see https://github.com/python/a
I think there's a plan to add a run() function to asyncio, which would be
something akin to
def run(coro):
return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Then you could start with `from asyncio import run` and from then on you'd
have your handy little fun
On other hand having builtin for making toy examples in interactive mode
looks very redundant.
On Sat, Nov 12, 2016 at 10:38 PM Ivan Levkivskyi
wrote:
> Hi,
>
> async/await syntax is a very nice recent feature, but there is something
> that I miss for coroutines defined with async def, as compar
Hi,
async/await syntax is a very nice recent feature, but there is something
that I miss for coroutines defined with async def, as compared to
generators. Coroutines represent an interesting mental model that goes
beyond only asynchronous IO, so that I play with them in REPL often. But
there is no
