(original) (raw)
On Nov 18, 2017 19:20, "Nick Coghlan" <ncoghlan@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