[Python-Dev] Python initialization and embedded Python

[Eric Snow]

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.

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

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