Logged In: YES 
user_id=31435

I certainly want, e.g., that our Unicode implementation can 
choose to use obmalloc.c for its raw string storage, 
despite that it isn't "object storage" (in the sense of 
Vladimir's level "+2" in the diagram at the top of 
obmalloc.c; the current CVS code restricts obmalloc use to 
level +2, while raw string storage is at level "+1").

Allowing to use pymalloc at level +1 changes Vladimir's 
original intent, and we have no experience with it, so I'm 
fine with restricting that ability to the core at the start.

About names, we've been calling this package "pymalloc" for 
years, and the general form of external name throughout 
Python is

    ["_"] "Py" Package "_" Function

_PyMalloc_{Malloc, Free, etc} fit that pattern perfectly.  
I don't see the attraction to giving functions from this 
package idiosyncratic names, and we've got so many ways to 
spell "get memory" that I expect it will be a genuine help 
to keep on making it clear, from the name alone, to 
which "family" a given variant of "new" (etc) belongs.