This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

Author larry
Recipients ajaksu2, dalcinl, larry
Date 2009-04-01.18:52:35
SpamBayes Score 9.558632e-12
Marked as misclassified No
Message-id <1238611957.45.0.259940616737.issue5630@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-04-01 18:52:37larrysetrecipients: + larry, dalcinl, ajaksu2
2009-04-01 18:52:37larrysetmessageid: <1238611957.45.0.259940616737.issue5630@psf.upfronthosting.co.za>
2009-04-01 18:52:36larrylinkissue5630 messages
2009-04-01 18:52:35larrycreate