Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warnings operate out of global runtime state. #80918

Closed
ericsnowcurrently opened this issue Apr 26, 2019 · 4 comments
Closed

Warnings operate out of global runtime state. #80918

ericsnowcurrently opened this issue Apr 26, 2019 · 4 comments
Assignees
Labels
3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes topic-subinterpreters type-bug An unexpected behavior, bug, or error

Comments

@ericsnowcurrently
Copy link
Member

BPO 36737
Nosy @brettcannon, @ericsnowcurrently, @zooba
PRs
  • bpo-36737: Use the module state C-API for warnings. #13159
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ericsnowcurrently'
    closed_at = <Date 2019-05-10.17:30:26.460>
    created_at = <Date 2019-04-26.22:28:58.200>
    labels = ['expert-subinterpreters', '3.8', 'type-bug', '3.7', '3.9']
    title = 'Warnings operate out of global runtime state.'
    updated_at = <Date 2020-05-15.00:37:35.654>
    user = 'https://github.com/ericsnowcurrently'

    bugs.python.org fields:

    activity = <Date 2020-05-15.00:37:35.654>
    actor = 'vstinner'
    assignee = 'eric.snow'
    closed = True
    closed_date = <Date 2019-05-10.17:30:26.460>
    closer = 'eric.snow'
    components = ['Subinterpreters']
    creation = <Date 2019-04-26.22:28:58.200>
    creator = 'eric.snow'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 36737
    keywords = ['patch']
    message_count = 4.0
    messages = ['340951', '340987', '340988', '342083']
    nosy_count = 3.0
    nosy_names = ['brett.cannon', 'eric.snow', 'steve.dower']
    pr_nums = ['13159']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue36737'
    versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']

    @ericsnowcurrently
    Copy link
    Member Author

    (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.

    @ericsnowcurrently ericsnowcurrently added interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes type-bug An unexpected behavior, bug, or error labels Apr 26, 2019
    @zooba
    Copy link
    Member

    zooba commented Apr 27, 2019

    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.

    @ericsnowcurrently
    Copy link
    Member Author

    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. :)

    @ericsnowcurrently
    Copy link
    Member Author

    New changeset 86ea581 by Eric Snow in branch 'master':
    bpo-36737: Use the module state C-API for warnings. (gh-13159)
    86ea581

    @ericsnowcurrently ericsnowcurrently self-assigned this May 10, 2019
    @vstinner vstinner added topic-subinterpreters and removed interpreter-core (Objects, Python, Grammar, and Parser dirs) labels May 15, 2020
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes topic-subinterpreters type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants