(original) (raw)

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" <storchaka@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