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

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