[pypy-dev] cppyy and callbacks

[wlavrijsen at lbl.gov]

Hi Alex,

> (I'm a little unclear what it means to represent "void*" as an array (array
> of what?),

exactly. A PyCObject is useless by design (but lacking in PyPy AFAICT, other
than in cpyext, which use would be slow), as is an array of void. It is the
best equivalent I could come up with ...

I figured that the only thing I ever wanted from a PyCObject, is to get the
C-side address. That is why cppyy.addressof() does provide that for arrays
of void now.

Beyond that, PyCObject's serve to go from C -> Python -> C, with no work in
Python. This void array can do that. The only part missing is an as_cobject
(one that returns a cpyext-based, CPython PyCObject), to communicate with
other extension libraries that use the CPython C-API. Such a function is
needed for all other C++ instances also, so I'll add that (PyROOT has it to
allow integration with PyQt, for example).

> Out of curiosity, is there some reason you didn't name that cppyy.gbl.NULL
> instead?  It seems to me that "nullptr" could potentially cause namespace
> collisions if some library decided to have a function/variable by that
> name, whereas "NULL" would be consistent with standard C++ naming..

Is unlikely, as 'nullptr' is a C++11 keyword. I've been thinking of putting
it under 'cppyy' rather than 'cppyy.gbl', but the latter seemed to make more
sense (it's not a module feature, but a C++ feature).

> For clarification, the specific use case I'm looking at is
> objects/functions that use "void *" as an "opaque pointer to application
> data" that the library doesn't want/need to care about (just pass back to
> the application sometimes).  In this context, it would be really nice if
> there was some easy way to use "void*" to represent a pure Python object as
> well (not just C++ instances).

Okay, I understand better now.

> Obviously, in pypy objects don't have
> static addresses, so we can't just use a pointer to the Python object

That is solvable (cppyy can bind functions that take/provide PyObject* as it
simply hands over the work to cpyext). See for example test_crossing.py in
pypy/module/cppyy/test. The larger problem would be that any randomly given
python object does not have a guaranteed layout.

> but
> I was considering the possibility of taking an index or id() of the object
> and just casting it into "void*" form, and then converting it back and
> using it to look up objects in a list/dict somewhere..

Alex Pyattaev did this (is in the pypy-dev mail archives, somewhere around
early Summer 2012).

> In any case, I wanted to make sure that use case was something that would
> be feasible in your plan for how void pointers will ultimately work..

Let me know if you see anything missing. "void*" is an interesting puzzle,
without many people (that I know of) interested in it.

The much bigger pain that we have, is the use of "char*" where the intended
usage is "byte*". (And I don't actually have a solution for that.)

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net