[Skip Montanaro]
> I think reducing the number of elements per category would also be of
> practical value, if for no other reason than it would reduce the mind
> boggling choice of potential functions for any one operation.
That's why it may be good to get rid of umpteen ways to spell "free". OTOH,
once you start life with a PyObject_XXX "get memory" function, it grates to
to spell "free memory" via PyMem_{Free, Del}; likewise vice versa. The
artificial Free/Del distinction there doesn't help anything.
Lapses from orthogonality also complicate life. For example, there are no
macro spellings for any function in the PyObject_GC_XXX family, but almost
<wink> all other functions in all other familes come in both flavors. And
while PyObject_GC_ has a Resize function for var objects, the PyObject_ and
new PyMalloc_ families do not. OTOH, the *non*-object PyMem_XXX family does
have a Resize (as well as a Realloc)!
One simplification: deprecate the entire PyObject_XXX family. We
introduced PyMalloc_XXX to do what PyObject_XXX was *supposed* to be used
for; it's "only" backward compatibility that argued for introducing
PyMalloc_XXX instead. OTOH, deprecating PyObject_XXX isn't a simplification
extension authors are likely to appreciate at first <wink>.
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