This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Warnings operate out of global runtime state.
Type: behavior Stage: resolved
Components: Subinterpreters Versions: Python 3.9, Python 3.8, Python 3.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: eric.snow Nosy List: brett.cannon, eric.snow, steve.dower
Priority: normal Keywords: patch

Created on 2019-04-26 22:28 by eric.snow, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 13159 merged eric.snow, 2019-05-07 16:15
Messages (4)
msg340951 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-04-26 22:28
(See Include/internal/pycore_warnings.h and Python/_warnings.c.)

The warnings module's state (filters, default action, etc.) is currently stored at the level of the global runtime.  That's a problem for the following reasons:

* Python objects are getting stored in _PyRuntimeState
* it breaks the isolation of behavior between interpreters
* objects are leaking between interpreters
* importing the module in a subinterpreter effectively resets the module's state

While those are all a problem in a future where interpreters don't share the GIL, that last one is a problem right now for people using subinterpreters.

One of the following should happen:

* move warnings state down to PyInterpreterState
* move warnings state into PyInterpreterState.dict
* use the module-state API (PEP 3121)
* just work out of the module's __dict__

I could also see use cases for *also* configuring warnings process-wide but that could be handled separately if actually desired.
msg340987 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-04-27 14:39
> I could also see use cases for *also* configuring warnings process-wide but that could be handled separately if actually desired.

Beyond "warning configuration is inherited by new interpreters", I don't see any reason to have process wide configuration. People using Python directly will get "process" wide from runtime configuration, and embedders don't want anything implicitly process-wide at all.
msg340988 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-04-27 15:05
Good point.

Also, the whole idea of inheriting things (settings, some copied objects, etc.) into subinterpreters is interesting.  My initial reaction is that folks would appreciate that feature, at least for a handful of things.  It's not critical, but is worth adding to the list of deferred ideas in PEP 554. :)
msg342083 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-05-10 17:29
New changeset 86ea58149c3e83f402cecd17e6a536865fb06ce1 by Eric Snow in branch 'master':
bpo-36737: Use the module state C-API for warnings. (gh-13159)
Date User Action Args
2022-04-11 14:59:14adminsetgithub: 80918
2020-05-15 00:37:35vstinnersetcomponents: + Subinterpreters, - Interpreter Core
2019-05-10 17:30:26eric.snowsetstatus: open -> closed
assignee: eric.snow
resolution: fixed
stage: patch review -> resolved
2019-05-10 17:29:57eric.snowsetmessages: + msg342083
2019-05-07 16:15:40eric.snowsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request13078
2019-04-27 15:05:15eric.snowsetmessages: + msg340988
2019-04-27 14:39:55steve.dowersetmessages: + msg340987
2019-04-26 22:28:58eric.snowcreate