STINNER Victor added the comment:
> *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)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24571>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
