➜
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.
Created on 2017-05-23 05:24 by eric.snow, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 1748 | merged | eric.snow, 2017-05-23 05:24 | |
| PR 1802 | closed | eric.snow, 2017-05-24 23:29 | |
| PR 1803 | closed | eric.snow, 2017-05-24 23:31 | |
| Messages (5) | |||
|---|---|---|---|
| msg294225 - (view) | Author: Eric Snow (eric.snow) *  |
Date: 2017-05-23 05:24 | |
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. |
|||
| msg294501 - (view) | Author: Eric Snow (eric.snow) * |
Date: 2017-05-25 17:15 | |
proposed: https://mail.python.org/pipermail/python-ideas/2017-May/045765.html |
|||
| msg294529 - (view) | Author: Alyssa Coghlan (ncoghlan) * |
Date: 2017-05-26 03:15 | |
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. |
|||
| msg310315 - (view) | Author: Eric Snow (eric.snow) * |
Date: 2018-01-20 01:59 | |
FYI, I'm working on a low-level patch for use in the test suite for 3.7. See issue #32604. |
|||
| msg368897 - (view) | Author: STINNER Victor (vstinner) * |
Date: 2020-05-15 01:18 | |
I mark this issue as a duplicate of bpo-32604. |
|||