On Sat., 16 Nov. 2019, 8:26 am Nathaniel Smith, <n...@pobox.com> wrote:
> As you know, I'm skeptical that PEP 554 will produce benefits that are > worth the effort, but let's assume for the moment that it is, and > we're all 100% committed to moving all globals into the threadstate. > Even given that, the motivation for this change seems a bit unclear to > me. > > I guess the possible goals are: > > - Get rid of the "ambient" threadstate entirely > - Make accessing the threadstate faster > - Eventually make it easier for CPython maintainers to know which functions require access to a live thread state, and which are stateless helper functions - Eventually make it easier for embedding applications to control which Python code runs in which thread state by moving the thread state activation dance out of the application and into the CPython shared library (We actually broke the thread state activation in hexchat not that long ago - there was a subtle latent defect in how they were handling it, and the changes to interpreter cleanup escalated it to a full blown crash) The need for the implicit thread state is never going to go away, but there are definitely opportunities to make the way we manage it less bug prone. (e.g. In the HPy work, I would expect each handle to be at least bound to an interpreter, and there could even be a higher level construct to associate callbacks with a specific thread state) Cheers, Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YIAVY4QFRNLO6FBVFHZNSFCBNLJ4WIGV/ Code of Conduct: http://python.org/psf/codeofconduct/
