Re: [Python-Dev] Python 2.3 release schedule

Tim Peters <tim.one@comcast.net> writes:
[Michael Hudson]
Surprise of the day: this [is all that's required!]:
#if PY_VERSION_HEX < 0x01060000 /* raw memory interface already present */
/* there is no object memory interface in 1.5.2 */ #define PyObject_Malloc(size) PyMem_Malloc((size)) #define PyObject_Realloc(p, size) PyMem_Realloc((p), (size)) ...
How come not the simpler
#define PyObject_Malloc PyMem_Malloc #define PyObject_Realloc PyMem_Realloc
etc instead? Filling in an argument list prevents use of a name as a function designator.
I thought filling out the arguments was better style, for some reason. Easy enough to change.
... /* There are three "families" of memory API: the "raw memory", "object memory" and "object" families.
Raw Memory:
PyMem_Malloc, PyMem_Realloc, PyMem_Free
Object Memory:
PyObject_Malloc, PyObject_Realloc, PyObject_Free
Object:
PyObject_New, PyObject_NewVar, PyObject_Del
I rarely mention the PyObject_GC_XYZ family because it's already in good shape. But its API changed between 2.1 and 2.2, and it would be good to supply a compatibility layer for it too. Pick Neil's brain <wink>.
I was under the impression that the 2.1 and 2.2 interfaces differed in ways that couldn't easily be papered over with macros. I'll check.
... Comments, flames, etc appreciated.
I especially liked the (snipped) to-the-point comment blocks;
Thanks; I think it is a good idea to describe intended usage in no uncertain terms *somewhere* at least. Probably lots of places. Any book authors reading python-dev?
PyObject_Del problems were already mentioned; thank you!
I hope it helps! Cheers, M. -- Famous remarks are very seldom quoted correctly. -- Simeon Strunsky

Michael Hudson wrote:
I was under the impression that the 2.1 and 2.2 interfaces differed in ways that couldn't easily be papered over with macros. I'll check.
It's not pretty. Look at pyexpat.c for an example. Perhaps something like this would be good enough (untested): #if PY_VERSION_HEX < 0x020200B1 #define PyObject_GC_New PyObject_New #define PyObject_GC_NewVar PyObject_NewVar #define PyObject_GC_Del PyObject_Del #define PyObject_GC_Track(op) #define PyObject_GC_UnTrack(op) #endif People could then always use the 2.2 API but the objects would only be collected in versions >= 2.2. Using the 2.1 API is a fair bit trickier and you can't hide those differences using macros (although you could make it easier for people who want to support 2.1 and >=2.2). Neil

On Tue, May 28, 2002, Michael Hudson wrote:
Thanks; I think it is a good idea to describe intended usage in no uncertain terms *somewhere* at least. Probably lots of places. Any book authors reading python-dev?
Yes. However, I'm no C programmer, and feedback on my book proposal makes it likely that API stuff will be dumped -- which is fine with me. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler
participants (3)
-
Aahz
-
Michael Hudson
-
Neil Schemenauer