[Python-Dev] Python initialization and embedded Python (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Mon Nov 20 10:31:32 EST 2017

On Nov 18, 2017 19:20, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

OK, in that case I think the answer to Victor's question is:

  1. Breaking calling Py_DecodeLocale() before calling Py_Initialize() is a compatibility break with the API implied by our own usage examples, and we'll need to revert the breakage for 3.7,

+1

The break was certainly unintentional. :/ Fortunately, Py_DecodeLocale() should be the only "Process-wide parameter" needing repair. I suppose, PyMem_RawMalloc() and PyMem_RawFree() could be considered too, but my understanding is that they aren't really intended for direct use (especially pre-init).

and ensure at least one release's worth of DeprecationWarning before requiring either the use of an alternative API (where the caller controls the memory management), or else a new lower level pre-initialization API (i.e. making PyRuntime_Initialize a public API)

There shouldn't be a need to deprecate anything, right? We just need to restore the pre-init behavior of Py_DecodeLocale.

  1. We should provide a consolidated list of these functions in the C API initialization docs

+1

PyMem_Raw*() do not belong in that group, right? Again, my understanding is that they aren't intended for direct third-party use (are they even a part of the C-API?), and particularly pre-init. That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an implementation detail.

  1. We should add more test cases to _testembed.c that ensure they all work correctly prior to Py_Initialize (some of them are already tested there, but definitely not all of them)

+1

-eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171120/c49d1fcd/attachment.html>

More information about the Python-Dev mailing list