[Python-Dev] Activating pymalloc

[Tim Peters]

[Tim]
>> but the crucial phrase "the same memory API family" is left undefined.

[martin@v.loewis.de]
> I always thought the notion of a "memory API family" is fairly obvious
> - none of those families has more than three members.

How do you know?  The phrase simply isn't defined.  "Fairly obvious" isn't
reference-doc quality, and I clearly disagreed the first time around that
"it's obvious".  That means it isn't <wink>.

> There is always one for allocation and one for deallocation, and
> perhaps one for reallocation. That's it.

Perhaps.

>> Like, are the functions and macros interchangeable?

> Of course not. You use the macros for efficiency, accepting that you
> incorporate the implementation in your code, which results in a
> depenency between the binary extension module and the binary Python
> installation.

I wasn't talking about efficiency or binary compatibility, just about what
(exactly) constitutes "same memory API family" (which, BTW, belongs in the
reference docs proper, not in the middle of a page of examples).

>> For example, if you know something was allocated via PyMem_Malloc,
>> is it OK to release it via PyMem_FREE?  I simply can't guess from
>> what the docs say, again because what constitutes "a family" is left
>> undefined.

> If you buy the notion of memory API families,

I'd be delighted to, if the concept were spelled out.

> you cannot deallocate the things this way.
> ...
> Of course, you will get away with mixing the macro and non-macro
> versions, at least if you are not crossing Python version boundaries.
> Do that and you are on your own, though (if desired, Python could
> easily guarantee that you can mix APIs in this way, but I see no need
> for that guarantee).

I see nothing in the docs either forbidding or allowing such mixture; your
view relies on the personal understanding of "memory API family" you've
fought your way to after making a focused study of the source code.
Extension authors aren't so conscientious, although I expect some have
picked up by now that all the macro forms have been "deprecated" outside the
core.

> ... If I can get the TeX to create a table for me, I'll see whether
> I can produce a table. More likely, Fred will have to fix it...

That would be great.  Fred can do this from a plain text table with ease --
wrestling with TeX shouldn't stand in the way.

>> The endless layers of indirection macros make this quite a pain

> I'm also uncomfortable with those. Fortunately, the family of the
> "object allocator" does not deserve being documented - I doubt anybody
> will ever need this. Also, the overriding hooks for replacing the
> function names and signatures don't need to be documented.

Agreed.

>> Which API?

> PyObject_MALLOC/REALLOC/FREE, and PyCore_* (both object and raw).

Gotcha.

>> In the Python source, the thread implementations use malloc and free
>> on purpose, but it also turns up a curious
> >
> > 		    free((char *)Py_FileSystemDefaultEncoding);
> [...]
>> Does that mean that, on Windows, we may free() a static char*?!

> Of course not. This is wrapped in
>
> #if defined(HAVE_LANGINFO_H) && defined(CODESET)
>
> neither of which is defined on Windows.

As I said, it's worthy of a comment.  *I* have no idea whether
HAVE_LANGINFO_H and/or CODESET are defined on Windows.  If the correctness
of this code *relies* on that they're not defined on Windows (as it still
appears it does), an "#if Windows ... #error" would even be appropriate.