Maybe we can find a compromise: revert the change on memory allocators. They are too special to require to call PyRuntime_Init().
Currently, you cannot call PyMem_SetAllocators() before PyRuntime_Init(). Victor Le 19 nov. 2017 08:55, "Serhiy Storchaka" <storch...@gmail.com> a écrit : > 19.11.17 04:17, Nick Coghlan пише: > >> 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, 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 is a way to to control the memory manager. The caller should just > define their own PyMem_RawMalloc(), PyMem_RawFree(), etc. It seems to me > that the reasons of introducing these functions were: > > 1. Get around the implementation detail when malloc(0) could return NULL. > PyMem_RawMalloc() always should return an unique address (unless error). > > 2. Allow the caller to control the memory management by providing their > own implementations. > > Let use existing possibilities and not expand the API. I don't think the > deprecation and breaking compatibility are needed here. > > _______________________________________________ > 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/victor. > stinner%40gmail.com >
_______________________________________________ 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
