gh-136380: Fix import behavior for concurrent.futures.InterpreterPoolExecutor#136381
gh-136380: Fix import behavior for concurrent.futures.InterpreterPoolExecutor#136381sobolevn merged 15 commits intopython:mainfrom
Conversation
serhiy-storchaka
left a comment
There was a problem hiding this comment.
The downside of this is that _interpreters is now always imported.
Could you add tests? It is not easy, the tests should remove concurrent and all its submodules recursively from sys.module, and restore sys.module at the end. There are helpers for this somewhere, they can be private.
Misc/NEWS.d/next/Library/2025-07-07-22-12-32.gh-issue-136380.1b_nXl.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
…b_nXl.rst Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Found a way to test it by running the test within a subprocess. |
|
I didn't mean to hit the update button, sorry about that. |
Co-authored-by: sobolevn <mail@sobolevn.me>
Co-authored-by: sobolevn <mail@sobolevn.me>
…terPoolExecutor` (pythonGH-136381) (cherry picked from commit 490eea0) Co-authored-by: AN Long <aisk@users.noreply.github.com> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
|
GH-136420 is a backport of this pull request to the 3.14 branch. |
…eterPoolExecutor` (GH-136381) (#136420) gh-136380: Fix import behavior for `concurrent.futures.InterpreterPoolExecutor` (GH-136381) (cherry picked from commit 490eea0) Co-authored-by: AN Long <aisk@users.noreply.github.com> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
…terPoolExecutor` (python#136381) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
…terPoolExecutor` (python#136381) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
…terPoolExecutor` (python#136381) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
|
This broke tab completion and |
…terPoolExecutor` (python#136381) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
…terPoolExecutor` (python#136381) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
…nterpreterPoolExecutor` (pythonGH-136381) (python#136420) pythongh-136380: Fix import behavior for `concurrent.futures.InterpreterPoolExecutor` (pythonGH-136381) (cherry picked from commit 490eea0) Co-authored-by: AN Long <aisk@users.noreply.github.com> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: sobolevn <mail@sobolevn.me>
It's hard to write the test, but on my local machine, when remove the
_interpretersmodule or raise aModuleNotFoundErrorin the try branch, the behavior is correct compare to a normal non-exist field:We must
import _interpretersin__init__.pyto determine whether to append theInterpreterPoolExecutorto__all__. This may have a negative impact on importing performance.