[Skip Montanaro] > If I remember the discussion correctly, there's not really much (if > any) performance benefit to using the macro versions. This depends on which macro/function pair you're talking about. For example, PyMem_Free is less efficient than PyMem_FREE, and always will be. The discussion you're remembering was specically about some PyObject_XXX spellings. There are no "general principles" here, and the attempt to introduce some did so at the cost of wishing away a decade of reality -- it's doomed to remain something of a mess now. > Since the the macro and function versions of each "function" seem > to be paired in your tables, True of the second table but not of the first. Read the whole message for why that's so. > why not simply define the macros to map to the functions for backward > compatibility and deprecate the macros altogether? See above. More valuable in the end would be to deprecate 6 of the 8 current ways to spell "free" that aren't already spelled "free". But nobody will agree to that, so no point. > That would have the added benefit of reducing your second table by > nearly half again. Reducing the number of *categories* would be of practical value. Even if we had no macro spellings at all, the second table would have the same number of categories as now.
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