Here's one from EVE, where the DB module creates raw data, for our Crowsets,
and then hands it over to another module for consumption (actual creation of
the CRow and CrowDescriptor objects:
BluePy raw(PyCObject_FromVoidPtr(&mColumnList, 0));
if (!raw)
return 0;
return PyObject_CallMethod(blueModule, "DBRowDescriptor", "O", raw.o);
This is done for performance reasons to avoid data duplication. Of course it
implies tight coupling of the modules.
In our FreeType wrapper system, we also use it to wrap pointers to FreeType
structs:
template <class T>
struct Wrapper : public T
{
...
PyObject *Wrap() {if (!sMap.size())Init(); return
PyCObject_FromVoidPtrAndDesc(this, &sMap, 0);}
};
It is quite useful to pass unknown and opaque stuff around with, really, and
makes certain things possible that otherwise wouldn't be.
We live with the type unsafety, of course.
In fact, I don't think we ever use a CObject to expose an API.
Kristj'an
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Guido
van Rossum
Sent: 2. apríl 2009 17:19
To: Jim Fulton
Cc: [email protected]
Subject: Re: [Python-Dev] Let's update CObject API so it is safe and regular!
On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton <[email protected]> wrote:
> The original use case for CObjects was to export an API from a module, in
> which case, you'd be importing the API from the module.
I consider this the *only* use case. What other use cases are there?
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
