[Cython] Ctypes object <-> pointer conversion.

[Robert Bradshaw]

On Thu, Aug 4, 2011 at 11:58 PM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 08/05/2011 01:31 AM, Robert Bradshaw wrote:
>>
>> This is getting a bit OT but is worth discussing, so I'm starting a new
>> thread.
>>
>> On Thu, Aug 4, 2011 at 2:51 PM, Greg Ewing<greg.ewing at canterbury.ac.nz>
>>  wrote:
>>>
>>> Dag Sverre Seljebotn wrote:
>>>
>>>>  - One idea is coercion of C pointers to ctypes Python objects and back
>>>> again.
>>>
>>> Some way of requesting this manually might be useful, but
>>> I don't think I'd like it to happen automatically. Slinging
>>> raw pointers around in Python isn't something to be done
>>> lightly -- even if all the code that dereferences it is
>>> in Cython, there are problems with managing the lifetime
>>> of whatever it references.
>>
>> You know, C has the same problem with slinging around raw pointers and
>> managing their lifetimes :). Of course, with C, the user is all to
>> painfully aware of the situation.
>>
>> I think this would be most useful for providing data from Python (even
>> an interactive prompt) to a Cython module. I agree about it being
>> dangerous to do implicitly, but something explicit like
>>
>> def entry_point(ctypes.CData x):
>>     cdef double* result = func(<int*>x)
>>     return<ctypes.CData>result   # or cytpes.CData(result,
>> option=...) to control deallocation
>>
>> could be really nice. Maybe CData could even be parameterized.
>
> This doesn't let you write
>
> cpdef int func(int *a): ...
>
> though.

I wasn't thinking of excluding this, but I'd was thinking

    cdef object o = ...
    int* x = o
    o = x

might be a compile-time error, forcing the user to be a bit more
explicit (especially the latter).

> My motivation for this was mainly to remove an exception from the
> rules, and make sure that every C level object .

?

> Although, C++ classes are another gaping exception to the rules.

On this note, what about SWIG-wrapped types?

> Perhaps
> just allowing the extension to 'cpdef' above but instead generate a stub
> that always raises a TypeError for the 'def' version is a better idea? That
> would allow fetching the docstring etc. from Python space, while the
> function remains uncallable. Even if we get int*<->ctypes.pointer, I propose
> this idea for C++ classes.

That's an interesting idea.

> But I can also see that it'd be really handy if you, say, have a huge API
> wrapped with ctypes, and want to gradually and piecewise move over to
> Cython. Or do some low-level integration between a ctypes wrapper and Cython
> wrapper.
>
> What's ctypes.CData? It's not in my ctypes module...

It's really _ctypes._CData.

- Robert