GeezerVison is showing github.com — Combined PR to show `ContextVar` changes together by nascheme · Pull Request #154647 · python/cpython
Conversation
nascheme
commented
Jul 24, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
This is a draft PR and is not meant to be merged as it. It shows the result after merging the following changes:
Related discussion is on Discourse.
Reasoning for each change:
ContextVar.thread_inheritable(): this new API is for libraries that want to convert global state to context-local state. It was intended that they should use ContextVar() since it acts like a thread-local and also switches context for asyncio tasks. However, ContextVar() has an issue in that new threads start with empty ContextVar bindings, they don't inherit the binding of the variable from the starting thread. This was an oversight but it has been how it works since contextvars was introduced. So changing it so threads do inherit is an incompatible change (effectively, this is turning the thread_inherit_context flag on by default). The ContextVar.thread_inheritable() API allows libraries to opt-in to what will be future behavior early. Suggest to merge for the 3.15 release.
- deprecation warning: this warning will help identify code that will be affected by changing the default of
thread_inherit_context to true. Ideally this warning should be in place for two releases before we change the default. Suggested to merge for the 3.16 release. Merging for 3.15 might be okay but I fear of people seeing new deprecation warnings that were not present in earlier 3.15 betas.
- Make
decimal.getcontext() return a fresh copy: this is required to avoid a bug if thread_inherit_context is true or if decimal starts using ContextVar.thread_inheritable() for its context. In that case, threads inherit the same mutable decimal.Context instance of the thread that spawned them. That's not thread safe and very likely not desired (e.g. a thread modifying the decimal context could affect the context of other threads). This bug exists in current Python if you explicitly set thread_inherit_context or if you use the free-threaded build, where that's set by default. Ideally this would be merged before 3.15 final since it's a bug.
- Future PR, use
ContextVar.thread_inheritable() for warnings and decimal: this change avoids deprecation warnings from these modules. Suggested to merge in 3.16. This changes decimal context slightly in the default (GIL-enabled) build (new threads start with a copy of the decimal context of the starter thread, rather than a copy of decimal.DefaultContext). IMHO, this is better but it is also an incompatible change.
In a future release (likely 3.18), we turn thread_inherit_context on by default. Then, ContextVar.thread_inheritable() and ContextVar() do the same thing. We can just leave thread_inheritable() as a soft-deprecated alias.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
On GIL-enabled builds, emit a DeprecationWarning when the default
implicitly empty threading.Thread() context causes a context variable
lookup to differ from the context that a future release will inherit by
default.
Context variables created this way will automatically be inherited by
the context for new threads, regardless of the setting of
`thread_inherit_context`.
We need a per-task copy of decimal.Context() so that mutations are
isolated between asyncio tasks and threads using
sys.flags.thread_inherit_context. This is done by adding a "depth"
counter to PyContext and copying the decimal.Context() instance whenever
it doesn't match the depth of the current PyContext.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Change `warnings` and `decimal` to use thread inheritable context vars.
This means new threads will start with bindings for these variables from
the starter thread, rather than having empty bindings (no matter the
value of the thread_inherit_context flag).
|
Closing this since the PRs are going to need some refinement before they are ready for merging.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
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.