[Python-Dev] Re: Review status policy [was: PEP 585: Type Hinting Generics ...]

I submitted a request for consideration to the Steering Council: https://github.com/python/steering-council/issues/21 - Ł > On 14 Mar 2020, at 21:30, Guido van Rossum wrote: > > Whoops. Here it is: https://github.com/python/steering-council/issues >

[Python-Dev] Proliferation of tstate arguments.

Hi, There seems to be a proliferation of `PyThreadState *tstate` arguments being added to API and internal functions. These changes are listed under https://bugs.python.org/issue38644. I think that these changes are misguided. The desired results can be achieved more reliably and more simply

[Python-Dev] Re: Proliferation of tstate arguments.

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.or

[Python-Dev] Re: Proliferation of tstate arguments.

Mark opened https://bugs.python.org/issue39978 "Vectorcall implementation should conform to PEP 590" where he wrote that passing tstate explicitly slows down PyObject_Vectorcall(). Victor Le lun. 16 mars 2020 à 15:16, Mark Shannon a écrit : > > Hi, > > There seems to be a proliferation of `PyThr

[Python-Dev] Re: Proliferation of tstate arguments.

There were quick discussions about using thread local storage (TLS) to get and set the current Python thread state ("tstate"), instead of reading/setting an atomic variable (_PyRuntime.gilstate.tstate_current). In fact, TLS already exists as "PyGILState" and PyGILState_GetThisThreadState() can alr