[issue38306] High level API for loop.run_in_executor(None, ...)?

Guido van Rossum added the comment: Really closing. -- nosy: +gvanrossum stage: -> resolved status: open -> closed ___ Python tracker ___

[issue38306] High level API for loop.run_in_executor(None, ...)?

Antoine Pietri added the comment: Yeah I'm pretty sure this solves it: https://github.com/python/cpython/pull/20143 Closing the issue, thanks. -- resolution: -> fixed ___ Python tracker

[issue38306] High level API for loop.run_in_executor(None, ...)?

Chris Jerdonek added the comment: Is this issue the same as this one? https://bugs.python.org/issue32309 -- nosy: +chris.jerdonek ___ Python tracker ___

[issue38306] High level API for loop.run_in_executor(None, ...)?

Antoine Pietri added the comment: 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. -- ___ Python tracker

[issue38306] High level API for loop.run_in_executor(None, ...)?

Caleb Hattingh added the comment: 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. --

[issue38306] High level API for loop.run_in_executor(None, ...)?

Antoine Pietri added the comment: On Sat, Oct 12, 2019 at 1:24 PM Caleb Hattingh 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

[issue38306] High level API for loop.run_in_executor(None, ...)?

Caleb Hattingh added the comment: 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

[issue38306] High level API for loop.run_in_executor(None, ...)?

Antoine Pietri added the comment: > 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

[issue38306] High level API for loop.run_in_executor(None, ...)?

Andrew Svetlov added the comment: 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. -- ___ Python tracker

[issue38306] High level API for loop.run_in_executor(None, ...)?

Paul Martin added the comment: run_in_executor doesn't necessarily create a new thread each time so create_thread would be misleading. run_in_thread might be better. -- nosy: +primal ___ Python tracker

[issue38306] High level API for loop.run_in_executor(None, ...)?

Antoine Pietri added the comment: 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)

[issue38306] High level API for loop.run_in_executor(None, ...)?

New submission from Antoine Pietri : 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