On Nov 18, 2017 19:20, "Nick Coghlan" <ncogh...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
