Victor Stinner wrote:
> I started to modify Python internals to pass explicitly the Python
> thread state ("tstate") to internal C a functions:Is work this summarized somewhere like a PEP? > https://vstinner.github.io/cpython-pass-tstate.html describes the motivation, but not the details on why what is changed. In particular, I am wondering what proportion of functions actually need the tstate, vs. how often it would just be adding some extra pack-pass-unpack work for no purpose. > To me, it sounds like a good practice to pass the current Python > thread state to internal C functions. Only if they need it (see above) and the passed data is at least as reliable as what they would get by using the current process. If the current process always gets the right answer, and the new process can sometimes gets the wrong one (even just through human error), that seems like a high price to pay. > ... Later, even "None" > singleton (and all other singletons) should be made "per interpreter". > [ later no objects should be shared ] At that point, it makes sense to feed them from different memory pools, and I am not sure how much advantage there is to a separate interpreter as opposed to a separate process. _______________________________________________ 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/6NM2PUXODK5EU7W2R6JKK2OE4MILTZXA/ Code of Conduct: http://python.org/psf/codeofconduct/
