On Thu, 9 Jan 2020 at 01:49, Victor Stinner <vstin...@python.org> wrote: > The question is now if we should "propagate" tstate to function calls > in the latest VECTORCALL calling convention (which is currently > private). Petr Viktorin plans to make VECTORCALL APIs public in Python > 3.9, as planned in the PEP 590: > https://bugs.python.org/issue39245
The vectorcall convention places a significant emphasis on speed, so being able to do a single PyThreadState_Get() call on the initial transition from Python to C, and then pass the thread state explicitly after that would make a lot of sense. So I think this is a good idea, but we might need to place a caveat on Python 3.9 that passing in a thread state that is NOT the currently active thread state may not work correctly yet (it's going to take a while to make sure that we never inadvertently call back into "implicit thread state" APIs from the implementation of APIs that accept an explicit thread state, and even after CPython itself is fixed, there's no telling what other extension modules might be doing). The transition to the full public vectorcall API already keeps the underscore prefixed versions around as aliases, so if the public API changes to accept an explicit thread state, then the underscore prefixed versions can be kept as wrapper functions that implicitly use the current thread state. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/TPKHV5G2LNZYUH33E3QEIO5OIVUEWF2P/ Code of Conduct: http://python.org/psf/codeofconduct/
