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.

Author steve.dower
Recipients eric.snow, jdemeyer, ncoghlan, steve.dower, vstinner
Date 2019-04-27.14:35:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1556375733.39.0.108405760679.issue36710@roundup.psfhosted.org>
In-reply-to
Content
Changing every API to take the context parameter would bring us into alignment with the JavaScript VMs.

I'm working on a project that embeds a few of these, as well as Python, and our thread management is much worse than their context parameter. Though I'm of course very sympathetic to the compatibility argument (but then the shims would just load the context from TSS and pass it around, so they're not too bad).

Eric's breakdown of context scopes seems spot on, and it means that we only really need the thread state to be passed around. The few places that would be satisfied by runtime state now (GIL, GC) should become interpreter state, which is most easily found from a thread state anyway.

Runtime state should eventually probably become runtime configuration (those settings we need to create interpreters) and a minimum amount of state to track live interpreters. I see no reason to pass it around anywhere other than interpreter creation, and as a transitional step toward that goal it should be accessible through the active interpreter state.
History
Date User Action Args
2019-04-27 14:35:33steve.dowersetrecipients: + steve.dower, ncoghlan, vstinner, eric.snow, jdemeyer
2019-04-27 14:35:33steve.dowersetmessageid: <1556375733.39.0.108405760679.issue36710@roundup.psfhosted.org>
2019-04-27 14:35:33steve.dowerlinkissue36710 messages
2019-04-27 14:35:33steve.dowercreate