In 3.7 a lot of high level functions have been added to the asyncio API, but nothing to start blocking functions as non-blocking threads. You still have to call get_event_loop() then await loop.run_in_executor(None, callable). I think this pattern is *very* common and could use a higher level interface.

Would an API like this make sense?

async def create_thread(callable, *args, *, kwargs=None, loop=None, timeout=None)

Then it could just be used like this:

await asyncio.create_thread(my_blocking_read, 4096, timeout=10)

This API could wrap the run_in_executor in an asyncio.Task, that way
you wouldn't have to await it to start the thread. There's evidence
that this has confused people in the past:

https://stackoverflow.com/questions/54263558/is-asyncio-run-in-executor-specified-ambiguously

Actually I don't think it's possible with the current implementation to cancel the concurrent.Future after a timeout, so maybe we should remove that argument. So, this signature instead:

async def create_thread(callable, *args, *, kwargs=None, loop=None)

run_in_executor doesn't necessarily create a new thread each time so create_thread would be misleading. run_in_thread might be better.

I'd like to see how thread pools integrate with (not existing yet bug planned for 3.9) task groups before pushing forward the proposed approach.

> run_in_executor doesn't necessarily create a new thread each time so create_thread would be misleading. run_in_thread might be better.

Right, the idea was to have an analogy with create_task, because the run_in_executor would be wrapped in a Task. I'm okay with run_thread() too.

Even before task groups land, this API can be easily improved by adding

asyncio.run_in_executor(func, *args, **kwargs)

- Only valid inside a coro or async context (uses get_running_loop internally)
- Analogous to how `loop.create_task` became `asyncio.create_task`
- Drop having to specify `None` for the default executor
- Users already know the `run_in_executor` name
- Allow both positional and kwargs (we can partial internally before calling loop.run_in_executor)

On Sat, Oct 12, 2019 at 1:24 PM Caleb Hattingh <report@bugs.python.org> wrote:
> Even before task groups land, this API can be easily improved by adding
>
> asyncio.run_in_executor(func, *args, **kwargs)
>
> - Only valid inside a coro or async context (uses get_running_loop internally)
> - Analogous to how `loop.create_task` became `asyncio.create_task`
> - Drop having to specify `None` for the default executor
> - Users already know the `run_in_executor` name
> - Allow both positional and kwargs (we can partial internally before calling loop.run_in_executor)

I think it should be run_thread() if it only works for thread.
run_in_executor() should take an executor= parameter, but it wouldn't
be as clear for beginners. I think there's value in having a simple,
explicit way of saying "I want to run this function in a thread"
without having to know what executors are.

We can't allow both an `executor=` kwarg, as well as **kwargs for the target func, unfortunately. If we do `executor=`, we'll again have to force users to use functools.partial to wrap their functions that take kwargs.

Yes, that's why I'm in favor of calling it run_thread. Because it
fundamentally *isn't* a way to run a function in an executor, it's a
way to run a function in a thread.

Is this issue the same as this one? https://bugs.python.org/issue32309

Yeah I'm pretty sure this solves it: https://github.com/python/cpython/pull/20143

Closing the issue, thanks.

Really closing.