dalcinl:

I made the destructor the first argument because APIs where arguments
move around irritate me.  In the existing CObject API, the destructor is
"always" the last argument--which means in practice it is either the
second or third argument, depending on which one you call.  I also think
that the destructor is a different kind of argument from the rest; the
others are data attributes for the object, and the destructor is a
callback.  I wanted to group the data attributes together.

We don't really need two different calls for providing a context
pointer, and if folks thought the shorter call should go we can get rid
of it.  But 90% of the time all you'll need .  Also, the new API grew
out of the existing API, which had a similar two calls
(PyCObject_FromVoidPtr, and PyCObject_FromVoidPtrAndDesc).

As for your "comment", I see CObject as a lightweight way of making a
generic "handle" type to represent C data structures without going to
the trouble of a real PyTypeObject.  I think the "storing functions in a
vtable then hiding it in the Python symbol table for other modules" use
case is a misuse of the API.  While I'm not going to actively prevent
it, I certainly wouldn't do anything to support it.