Logged In: YES 
user_id=6380

(Wouldn't it be more efficient to take this to email
between the three of us?)

> 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.

Still, tradition has it that we keep such entry
points around for a long time.  I propose that we do
so now, too.

> 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.

Huh?  "destructor" is used to declare tp_dealloc,
which definitely needs a PyObject * (or some
"subclass" of it, like PyIntObject *).

It's also used to declare tp_free, which arguably
shouldn't take a PyObject * (since by the time
tp_free is called, most of the object's contents
have been destroyed by tp_dealloc).  So maybe
tp_free (a newcomer in 2.2) should be declared to
take something else, but then the risk is breaking
code that defines a tp_free with the correct
signature.

> 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.

I don't understand this at all.

> 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.

Nor this.

> 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>.

I want binary compatibility, but I don't understand
your comments very well.

> 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.

I prefer PyObject_Del -- like PyObject_GC_Del, and
like we did in the past.  Plus, I like New to match
Del and Malloc to match Free.  Since it's
PyObject_New, it should be _Del.


I'm not sure what to say of Neil's patch, except
that I'm glad to be rid of the PyMalloc_XXX family.
I wish we didn't have to change all the places that
used to say _PyObject_Del.  Maybe it's best to keep
that name around?  The patch would (psychologically)
become a lot smaller.  I almost wish that this would
work:

#define PyObject_Del  ((destructor)PyObject_Free)

Or maybe it *does* work???