[issue36737] Warnings operate out of global runtime state.

Change by STINNER Victor : -- components: +Subinterpreters -Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36737] Warnings operate out of global runtime state.

Eric Snow added the comment: New changeset 86ea58149c3e83f402cecd17e6a536865fb06ce1 by Eric Snow in branch 'master': bpo-36737: Use the module state C-API for warnings. (gh-13159) https://github.com/python/cpython/commit/86ea58149c3e83f402cecd17e6a536865fb06ce1 --

[issue36737] Warnings operate out of global runtime state.

Change by Eric Snow : -- assignee: -> eric.snow resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36737] Warnings operate out of global runtime state.

Change by Eric Snow : -- keywords: +patch pull_requests: +13078 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36737] Warnings operate out of global runtime state.

Eric Snow added the comment: 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

[issue36737] Warnings operate out of global runtime state.

Steve Dower added the comment: > 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.

[issue36737] Warnings operate out of global runtime state.

New submission from Eric Snow : (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