[Guido]
> I prefer to sit down with you and go over this systematically. The
> asynchrony of email (and my lack of attention span when reading email
> while watching Orlijn) makes it hard to do a good job in email.
Here's a start: these are all the public-API get/resize/free names we
exposed in 2.2:
malloc, realloc, free
PyMem_{Malloc, Realloc, Free}
PyMem_{MALLOC, REALLOC, FREE}
PyMem_{New, Resize, Del}
PyMem_{NEW, RESIZE, DEL}
PyObject_{Malloc, Realloc, Free}
PyObject_{MALLOC, REALLOC, FREE}
PyObject_{New, NewVar, Del}
PyObject_{NEW, NEWVAR, DEL}
PyObject_GC_{New, NewVar, Resize, Del}
All that remains <wink> is to spell out the rules each follows in 2.3:
+ Is or isn't it deprecated? If it is deprecated, does that mean
something stronger than "should not use it, but may"? Does the
answer vary according to whether it's used in the core or in an
extension?
+ Does it guarantee binary compatibility across releases?
+ Under what conditions must the GIL be held when calling it?
+ Exactly which other memory functions can it be mixed with?
+ Can it be passed as an argument? That is, if N is one of names above,
is f(N) a supported use for user-defined C functions f?
The only non-interesting question (to me) is whether each is "really a
function" or "really a macro" -- that's an implementation detail, and C code
following the rules shouldn't care.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4