Combined PR to show ContextVar changes together#154647
Draft
nascheme wants to merge 6 commits into
Draft
Conversation
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.
Documentation build overview
6 files changed ·
|
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).
nascheme
force-pushed
the
ctx_thread_inherit_combined
branch
from
July 24, 2026 20:47
bdbb491 to
fbddda8
Compare
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
1 participant
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 is a draft PR and is not meant to be merged as it. It shows the result after merging the following changes:
thread_inherit_contextchange #154558ContextVar.thread_inheritable(). #154564warningsanddecimalto useContextVar.thread_inheritable().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 useContextVar()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 thethread_inherit_contextflag on by default). TheContextVar.thread_inheritable()API allows libraries to opt-in to what will be future behavior early. Suggest to merge for the 3.15 release.thread_inherit_contextto 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.decimal.getcontext()return a fresh copy: this is required to avoid a bug ifthread_inherit_contextis true or ifdecimalstarts usingContextVar.thread_inheritable()for its context. In that case, threads inherit the same mutabledecimal.Contextinstance 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 setthread_inherit_contextor 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.ContextVar.thread_inheritable()forwarningsanddecimal: this change avoids deprecation warnings from these modules. Suggested to merge in 3.16. This changesdecimalcontext 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 ofdecimal.DefaultContext). IMHO, this is better but it is also an incompatible change.In a future release (likely 3.18), we turn
thread_inherit_contexton by default. Then,ContextVar.thread_inheritable()andContextVar()do the same thing. We can just leavethread_inheritable()as a soft-deprecated alias.