This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients giampaolo.rodola, gvanrossum, ncoghlan, pitrou, srkunze, vstinner, yselivanov
Date 2015-07-07.15:36:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> *If* it needs to be added I like call_in_thread().

Except if you explicitly set the executor to a thread pool executor, the function name can be a lie. It's possible to modify the default executor to a process poll executor.

I vote -1 for the function. I would prefer to use directly event loop methods (run_in_executor).

   # Call blocking operation from asynchronous code
   def blocking_call(f, *args, **kwds):

This function name is very misleading. Calling blocking_call() doesn't return the result of f(*args, **kwds) but a Future object...

> The aim would thus be to let folks safely make blocking calls from asyncio code without needing to first understand the intricacies of the event loop, the event loop's executor, or the need to wrap the call in functools.partial.

I don't like the idea of hiding asyncio complexity. See eventlet monkey patching, it was a big mistake.

But ok to add helpers when they are revelant.

I also fear adding too many functions to do the same things.

For example, scheduling the execution of a coroutine can now be done by:

* asyncio.async(coro)
* asyncio.Task(coro)
* loop.create_task(coro)
* asyncio.ensure_task(coro)
Date User Action Args
2015-07-07 15:36:17vstinnersetrecipients: + vstinner, gvanrossum, ncoghlan, pitrou, giampaolo.rodola, yselivanov, srkunze
2015-07-07 15:36:17vstinnersetmessageid: <>
2015-07-07 15:36:17vstinnerlinkissue24571 messages
2015-07-07 15:36:17vstinnercreate