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 jamesba
Recipients jamesba
Date 2020-05-26.15:45:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1590507938.7.0.58927076005.issue40782@roundup.psfhosted.org>
In-reply-to
Content
As discussed in < https://github.com/python/typeshed/issues/3999#issuecomment-634097968 > the type of `AbstractEventLoop.run_in_executor` is defined at < https://github.com/python/cpython/blob/master/Lib/asyncio/events.py#L286 > as follows:

```
async def run_in_executor(self, executor, func, *args):
        raise NotImplementedError
```

However all concrete implementations of this method are actually not async methods but rather synchronous methods which return a Future object.

Logically this appears to make sense: at base `run_in_executor` is not a coroutine, since it doesn't create an object representing code which will be executed when the object is awaited, rather it returns an object representing code which is running asynchronously elsewhere (on another thread) and which can be awaited to wait for that other thread to complete its task. Which seems to be a perfect match to what a Future object is supposed to be.

As such it seems that the current definition of the method as a coroutine is possibly a mistake.

Alternatively if some feel that it is important to allow concrete implementations to implement it as a coroutine if they need to then perhaps it could be specified to be a method returning an Awaitable, since that would cover both options?
History
Date User Action Args
2020-05-26 15:45:38jamesbasetrecipients: + jamesba
2020-05-26 15:45:38jamesbasetmessageid: <1590507938.7.0.58927076005.issue40782@roundup.psfhosted.org>
2020-05-26 15:45:38jamesbalinkissue40782 messages
2020-05-26 15:45:38jamesbacreate