On Thu, Aug 4, 2011 at 11:58 PM, Dag Sverre Seljebotn
<d.s.seljeb...@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.ew...@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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
