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
BaseEventLoop.run_in_executor shouldn't specify max_workers for default Executor #70983
Comments
In bpo-21527 <http://bugs.python.org/issue21527\> the concurrent.futures.ThreadPoolExecutor was changed to have a default value for max_workers. When asyncio.base_events.BaseEventLoop.run_in_executor creates a default ThreadPoolExecutor it specifies a value of 5 for max_workers, presumably because at the time it was written ThreadPoolExecutor didn't have a default for max_workers. This is confusing because on reading the documentation for ThreadPoolExecutor one might assume that the default specified there is what will be used if a default executor isn't supplied via BaseEventLoop.set_default_executor. I propose that BaseEventLoop.run_in_executor be changed to not supply a default for max_workers. If this isn't acceptable, a note ought to be put in the run_in_executor documentation. |
I like this idea for 3.5 and later. I know this is a pain, but I would like the code to have a version check so that the identical code can still be used in Python 3.3 and 3.4. We go through great lengths to keep the asyncio package compatible with those versions so that we can occasionally push a version out to PyPI for 3.3 and 3.4 users. If the versions diverge we would be unable to keep track of other bug fixes. |
Thanks, that makes sense. I've attached a patch with a version check. |
There should at least be a comment at the definition of _MAX_WORKERS that it's only used on Python 3.4 and before. Maybe a note in the docs about the default executor would also be useful. Otherwise this is exactly what I had in mind -- thanks! PS. Could you sign a contributor form online |
New patch attached. Includes comments and a note in the documentation. The documentation note is inside a versionchanged:: 3.5 block. Should this be more specific about the version it changed in? It could be confusing for someone using a version of 3.5 that doesn't have the change. Contributor form is signed. Thanks! |
LGTM! |
New changeset 785597e758a1 by Yury Selivanov in branch '3.5': New changeset 99941cacfc38 by Yury Selivanov in branch '3.6': New changeset a475f2e39c6f by Yury Selivanov in branch 'default': |
Thank you, Hans! |
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: