gh-128384: Add thread-safe context manager to "warnings" module - #128300
Closed
nascheme wants to merge 9 commits into
Closed
gh-128384: Add thread-safe context manager to "warnings" module#128300nascheme wants to merge 9 commits into
nascheme wants to merge 9 commits into
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
nascheme
force-pushed
the
warnings_local_context
branch
from
1f8b441 to
3952bb0
Compare
December 28, 2024 21:07
Expose the mutex from _warnings.c and hold it when mutating the filters list.
By default, inherit the context from the thread calling `Thread.start()`.
nascheme
force-pushed
the
warnings_local_context
branch
from
3952bb0 to
3bac8d1
Compare
January 1, 2025 05:08
When reset is called, the warnings.filters list should be ignored since the list of active filters should be empty at that point.
Copy link
Copy Markdown
Member
Author
|
Closing this since gh-130010 seems a better approach. |
Sorry, something went wrong.
gst
reviewed
Apr 7, 2025
Comment thread
Lib/test/test_warnings/__init__.py
|
|
||
|
|
||
| class PyContextTests(ContextTests, unittest.TestCase): | ||
| module = c_warnings |
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
don't you want the other one ?
Sorry, something went wrong.
Copy link
Copy Markdown
Member
Author
There was a problem hiding this comment.
Yup, you're right.
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a new thread-local (and async friendly) context manager that uses contextvars. The recommended pattern for new code that doesn't care about backwards compatibility would be:
with warnings.local_context() as ctx: ctx.simplefilter(...) ...For code that wants to be compatible with older versions of Python, the suggested code is:
import warnings try: warn_ctx = warnings.get_context except AttributeError: def warn_ctx(): return warnings with warn_ctx().catch_warnings(): warn_ctx().simplefilter(...) ... with warn_ctx().catch_warnings(record=True) as log: ...This change retains warnings.filters and warnings.catch_warnings() as mechanisms that use process global state. Conceptually, there will be two sets of warning filters: the legacy process global warnings.filters list and the thread local get_context()._filters list. The context object returned by get_context() has an API that overlaps with the warnings module function API.
Perhaps we could eventually warn when the process global versions are used but I think that would be many years in the future and not worth considering now.
It would be intuitive if the thread local filtering was inherited when a new thread is created. I've created a separate PR that adds this feature to threading.Thread: gh-128209. That's a potentially controversial change but I think it's the correct thing to do. It will make contextvars behave similarly between asyncio tasks (which already inherit context) and threads. I think people will expect the warnings context manager to have lexical scope. If you see the code:
with warnings.local_context() as ctx: ctx.simplefilter(MyWarning) inner_function()Then you would assume that inner_function() is going to have MyWarning filtered, even if it internally spawns a thread.
Regarding backwards compatibility, I did a code search and there are quite a few examples for code that manipulates warnings.filters directly, either mutating it or assigning a different list to the module global. There is also code that does this:
📚 Documentation preview 📚: https://cpython-previews--128300.org.readthedocs.build/