[Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Aug 31 05:51:37 EDT 2017

On 31 August 2017 at 18:16, Masayuki YAMAMOTO <ma3yuki.8mamo10 at gmail.com> wrote:

Hi python-dev,

Since Erik started the PEP 539 thread on python-ideas, I've collected feedbacks in the discussion and pull-request, and tried improvement for the API specification and reference implementation, as the result I think resolved issues which pointed out by feedbacks. Well, it's probably not finish yet, there is one which bothers me. I'm not sure the CPython startup sequence design (PEP 432 Restructuring the CPython startup sequence, it might be a conflict with the draft specification [1]),

I think that's just a bug in the startup refactoring - we don't currently test the "Py_Initialize()/Py_Initialize()/Py_Finalize()" sequence anywhere, and I'd missed that it's explicitly documented as being permitted. I'd still want to keep the "multiple calls without an intervening finalize are prohibited" behaviour for the new more granular APIs (since it's simpler and easier to explain if it just always fails rather than attempting to check that the previous initialization supplied the same config settings), but the documented Py_Initialize() behaviour can be reinstated by restoring the early return in _Py_InitializeEx_Private.

It's also worth noting that we do test repeated Py_Initialize()/Py_Finalize() cycles - Py_Finalize() explicitly clears the internal flags that would otherwise lead to a fatal error in _Py_InitializeCore.

As far as the PEP itself goes, this version looks good to me, so if there aren't any other significant comments between now and then, I'm likely to accept it at the core development sprint next week.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list