You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bpo-32604: [subinterpreters] PEP 554 implementation: add interpreters module
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=<Date2020-05-15.01:18:14.078>created_at=<Date2017-05-23.05:24:25.443>labels= ['expert-subinterpreters', 'type-feature', '3.8']
title='[subinterpreters] Expose the subinterpreters C-API in the stdlib'updated_at=<Date2020-05-15.01:18:14.076>user='https://github.com/ericsnowcurrently'
For a variety of reasons, I'd like to be able to manage subinterpreters from Python code. An initial effort would add a _interpreters module to the stdlib that exposes the basic functionality of the corresponding C-API.
A naming suggestion: let's leave the interpreters & _interpreters names free for a possible future PEP to make this a public API with a fallback multiprocessing backed implementation for implementations that don't have native subinterpreter support.
Then for this "testing and experimentation only" API, we'd go with "_subinterpreters" to match the name typically used to refer to the CPython feature.
vstinner
changed the title
Expose the subinterpreters C-API in the stdlib.
[subinterpreters] Expose the subinterpreters C-API in the stdlib
May 15, 2020
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: