Hi, > Changes on this scale merit a PEP and proper discussion, rather than > being added piecemeal without proper review.
Last November, I asked explicitly on python-dev if we should "Pass the Python thread state to internal C functions": https://mail.python.org/archives/list/python-dev@python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/#Q4IPXMQIM5YRLZLHADUGSUT4ZLXQ6MYY In short, the answer is yes. There is no PEP but scatted documents. I wrote a short article to elaborate the context of this work: https://vstinner.github.io/cpython-pass-tstate.html One motivation is to ease the implementation of subinterpreters (PEP 554). But PEP 554 describes more than public API than the implementation. -- In the meanwhile, I modified "small integer singletons" to make them "per-interpreter". So tstate->interp is now used to get small integers in longobject.c. I also opened a discussion on other singletons (None, True, False, ...): https://bugs.python.org/issue39511 The long-term goal is to be able to run multiple isolated interpreters in parallel. Le lun. 16 mars 2020 à 15:16, Mark Shannon <m...@hotpy.org> a écrit : > There seems to be a proliferation of `PyThreadState *tstate` arguments > being added to API and internal functions. So far, tstate should only be passed to *internal* C functions. I don't think that the public C API has been modified to pass tstate. > These changes are listed under https://bugs.python.org/issue38644. There was also https://bugs.python.org/issue36710 > I think that these changes are misguided. The desired results can be > achieved more reliably and more simply in other ways. Would you mind to elaborate? > The changes add bulk to the C-API and may hurt performance. Did you notice that in benchmarks? I would be curious to see the overhead. > These changes are also causing a lot of churn and merge conflicts (for > me at least). Sorry about that :-/ A lot of Python internals should be modified to implement subinterpreters. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/FGU5YUJQTRB4HVP5Y36O7FIMYIW2OHZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
