[Python-Dev] Python initialization and embedded Python
Serhiy Storchaka
storchaka at gmail.com
Sun Nov 19 02:53:30 EST 2017
More information about the Python-Dev mailing list
Sun Nov 19 02:53:30 EST 2017
- Previous message (by thread): [Python-Dev] Python initialization and embedded Python
- Next message (by thread): [Python-Dev] Python initialization and embedded Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [Python-Dev] Python initialization and embedded Python
- Next message (by thread): [Python-Dev] Python initialization and embedded Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list