gh-128555: Add 'context' keyword parameter to Thread.

[nascheme]

By default, inherit the context from the thread calling Thread.start().

This was motivated by making the warnings module work more reliably when threads and asyncio are used in combination with catch_warnings. I'm working on a PR that will make warnings use a contextvar for the filtering state.

This is not a new idea, it was suggested around the 3.10 release timeframe, gh-86981.

---

📚 Documentation preview 📚: https://cpython-previews--128209.org.readthedocs.build/

• Issue: New threads should inherit the contextvars.Context of their creator #128555

[nascheme]

I wonder if threading.Thread is the correct layer to do this at. Perhaps it should be done at a lower level, e.g. inside Modules/_threadmodule.c.

[gpshead]

I think I'd make this more direct about the behavior change, perhaps something like:

"Threads now inherit the context of the caller of Thread.start instead of starting with an empty context. The context parameter was added. Pass a new contextvars.Context() if your thread requires an empty context."

This default change is a behavior change. Expect that to trip someones existing code up. I don't have the context (pun intended) as to how disruptive that could be. Per the PEP-387 breaking change policy we'd want to wait at least two releases. Which isn't so satisfying given the reasons you want this.

But a compromise could be considered (unsure if this is really wise) if needed: Change the default sooner than the deprecation when running in an experimental free-threading cpython build?