Skip to content

gh-112660: Do not clear arbitrary errors on import #112661

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

Merged

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Dec 3, 2023

Previously arbitrary errors could be cleared during formatting error messages for ImportError or AttributeError for modules. Now all unexpected errors are reported.

Previously arbitrary errors could be cleared during formatting error
messages for ImportError or AttributeError for modules. Now all
unexpected errors are reported.
@serhiy-storchaka serhiy-storchaka merged commit 8660fb7 into python:main Dec 7, 2023
@serhiy-storchaka serhiy-storchaka deleted the import-no-clear-error branch December 7, 2023 10:19
ericsnowcurrently added a commit that referenced this pull request Dec 7, 2023
gh-112853)

As of gh-112661, the threading module expects the _thread module to have a _is_main_interpreter(), which is used in the internal threading._shutdown().  This change causes a problem for anyone that replaces the _thread module with a custom one (only if they don't provide _is_main_interpreter()).  They need to be sure to add it for 3.13+, thus this PR is adding a note in "What's New".

This also forward-ports the "What's New" entry from 3.12 (gh-112850).  Note that we do not also forward-port the fix in that PR.  The fix is there only due to a regression from 3.12.0. There is no regression in 3.13+.
aisk pushed a commit to aisk/cpython that referenced this pull request Feb 11, 2024
…2661)

Previously arbitrary errors could be cleared during formatting error
messages for ImportError or AttributeError for modules. Now all
unexpected errors are reported.
aisk pushed a commit to aisk/cpython that referenced this pull request Feb 11, 2024
…rpreter (pythongh-112853)

As of pythongh-112661, the threading module expects the _thread module to have a _is_main_interpreter(), which is used in the internal threading._shutdown().  This change causes a problem for anyone that replaces the _thread module with a custom one (only if they don't provide _is_main_interpreter()).  They need to be sure to add it for 3.13+, thus this PR is adding a note in "What's New".

This also forward-ports the "What's New" entry from 3.12 (pythongh-112850).  Note that we do not also forward-port the fix in that PR.  The fix is there only due to a regression from 3.12.0. There is no regression in 3.13+.
Glyphack pushed a commit to Glyphack/cpython that referenced this pull request Sep 2, 2024
…2661)

Previously arbitrary errors could be cleared during formatting error
messages for ImportError or AttributeError for modules. Now all
unexpected errors are reported.
Glyphack pushed a commit to Glyphack/cpython that referenced this pull request Sep 2, 2024
…rpreter (pythongh-112853)

As of pythongh-112661, the threading module expects the _thread module to have a _is_main_interpreter(), which is used in the internal threading._shutdown().  This change causes a problem for anyone that replaces the _thread module with a custom one (only if they don't provide _is_main_interpreter()).  They need to be sure to add it for 3.13+, thus this PR is adding a note in "What's New".

This also forward-ports the "What's New" entry from 3.12 (pythongh-112850).  Note that we do not also forward-port the fix in that PR.  The fix is there only due to a regression from 3.12.0. There is no regression in 3.13+.
hauntsaninja added a commit to hauntsaninja/cpython that referenced this pull request Dec 17, 2024
…module

I missed the extra `PyModule_Check` in python#127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in python#112661.
hauntsaninja added a commit that referenced this pull request Dec 20, 2024
…#128047)

I missed the extra `PyModule_Check` in #127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in #112661.
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Dec 20, 2024
…module (pythonGH-128047)

I missed the extra `PyModule_Check` in pythonGH-127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in pythonGH-112661.
(cherry picked from commit 45e6dd6)

Co-authored-by: Shantanu <[email protected]>
hauntsaninja added a commit that referenced this pull request Dec 20, 2024
…-module (GH-128047) (#128114)

gh-128030: Avoid error from PyModule_GetFilenameObject for non-module (GH-128047)

I missed the extra `PyModule_Check` in GH-127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in GH-112661.
(cherry picked from commit 45e6dd6)

Co-authored-by: Shantanu <[email protected]>
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this pull request Dec 23, 2024
…module (python#128047)

I missed the extra `PyModule_Check` in python#127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in python#112661.
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this pull request Jan 8, 2025
…module (python#128047)

I missed the extra `PyModule_Check` in python#127660 because I was looking at
3.12 as the base implementation for import from. This meant that I
missed the `PyModuleCheck` introduced in python#112661.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant