New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying AbstractEventLoop.run_in_executor as a coroutine conflicts with implementation/intent #79973
Comments
Currently AbstractEventLoop.run_in_executor is specified as a coroutine, while BaseEventLoop.run_in_executor is actually a non-coroutine that returns a Future object. The behavior of BaseEventLoop.run_in_executor would be significantly different if changed to align with the interface . If run_in_executor is a coroutine then the provided func will not actually be scheduled until the coroutine is awaited, which conflicts with the statement in PEP-3156 that it "is equivalent to There has already been an attempt in bpo-32327 to convert this function to a coroutine. We should change the interface specified in |
I would rather change the implementation by converting it into async function. |
My use case is scheduling work against an executor but waiting on the results later (on demand). If converting impl.1) In both cases the provided For [impl.1], from the linked discussion, there is an example of user code required to get the behavior of schedule immediately and return future while still using async def run_now(f, *args):
loop = asyncio.get_event_loop()
started = asyncio.Event()
def wrapped_f():
loop.call_soon_threadsafe(started.set)
return f(*args)
fut = loop.run_in_executor(None, wrapped_f)
await started.wait()
return fut however this wrapper would only be possible to use in an async function and assumes the executor is running in the same process - synchronous functions (e.g. an implementation of Protocol.data_received) would need to use an alternative def my_run_in_executor(executor, f, *args, loop=asyncio.get_running_loop()):
return asyncio.wrap_future(executor.submit(f, *args), loop=loop) either of these would need to be discovered by users and live in their code base. Having to use For [impl.2], we are fine if the use case allows submitting and awaiting the completion of soln.1) use [soln.1] is bad for the reason stated above: this is the function we are trying to avoid users having to write. [soln.2] uses the low-level function |
For impl.1:
should be
|
This will be backwards incompatible change to change it to a coroutine and so far this doesn't seem to be a problem. I am -1 on changing this. |
In GH-21852, |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: