Logged In: YES 
user_id=31435

Extensions that *currently* call PyObject_Del have its old 
macro expansion ("_PyObject_Del((PyObject *)(op))") buried 
in them, so getting rid of _PyObject_Del is a binary-API 
incompatibility (existing extensions will no longer link 
without recompilation).

I personally don't mind that, but I run on Windows 
and "binary compatability" never works there across minor 
releases for other reasons, so I don't have any real feel 
for how much people on other platforms value it.  As you 
pointed out recently too, binary compatability has, in 
reality, not been the case since 1.5.2 anyway.

So that's one for Python-Dev.  If we do break binary 
compatibility, I'd be sorely tempted to change 
the "destructor" typedef to say destructors take void*.  
IMO saying they take PyObject* was a poor idea, as you 
almost never have a PyObject* when calling one of these 
guys.  That's why PyObject_Del "had to" be a macro, to hide 
the cast to PyObject* almost everyone needs because of 
destructor's "correct" but impractical signature. 
If "destructor" had a practical signature, there would have 
been no temptation to use a macro.

Note that if the typedef of destructor were so changed, you 
wouldn't have needed new casts in tp_free slots.  And I'd 
rather break binary compatability than make extension 
authors add new casts.

Hmm. I'm assigning this to Guido for comment:  Guido, what 
are your feelings about binary compatibility here?  C 
didn't define free() as taking a void* by mistake <wink>.

Back to Neil:  I wouldn't bother changing PyObject_Del to 
PyObject_Free.  The former isn't in the "recommended" 
minimal API, but neither is it discouraged.  I expect 
TMTOWTDI here forever.