Don't know how I missed this earlier. On Fri, Sep 14, 2012 at 10:39 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Robert Bradshaw, 15.09.2012 00:39: >> On Fri, Sep 14, 2012 at 2:29 PM, Dag Sverre Seljebotn wrote: >>> Isn't there a case for converting to/from ctypes pointers rather than >>> capsules? And if capsules, what would the secret word be? Hmm... >> >> +1, ctypes would be even better. It's not in the standard library >> 'till 2.5, but I don't think that's a huge blocker as it can be >> installed earlier. > > I'm not entirely sure I see the use case for starting to support the ctypes > type system. Is there more to it than just passing pointers through Python > code? A capsule (or even a special Cython extension type) sounds like a > better option. For example, it's rather unlikely that non-Cython user code > will start to support passing in ctypes types, so it would rather be a > Cython-to-Cython-only thing anyway.
My assumption is that it would allow more than just Cython-to-Cython translation. Essentially ctypes would be the lingua franca of, well, external C types like pointers and any library that needs (say) and int*, whether in Cython or not, could communicate this via Python space. I'ts just an idea, I haven't pursued it that far. The other option is forgoing type safety or rolling our own (which might be lightweight enough to just do). > Do you assume that users would want to access C internals through the > values that Cython returns to them? That sounds risky. True, but it could be useful as well. >>> Robert Bradshaw wrote: >>>> Given the CObject vs Capsule differences in Py2 vs Py3, and the >>>> clumsiness in using them (see below), any thoughts on automatically >>>> converting void* to/from a Python object? There is the sticky issue of >>>> pointer lifetime management, but we could assume the lifetime is >>>> managed entirely in C in most cases. >>>> >>>> Note that <void*>object already has a specific meaning that we can't >>>> hijack, but perhaps non-void* would be fine to do implicitly? Also, if >>>> we built this into the language, could we provide type safety via the >>>> name/description attribute? Something like this could be really handy >>>> to have and isn't as easily done as a library (especially given the >>>> 2/3 differences). > > We could support both use cases by adding both types to the type system. > For example: > > from cython import capsule > > cap = <capsule[description]>some_ptr > > or, likely nicer: > > cap = capsule(some_ptr, description) > > with auto-fallback to CObject on older Py2 versions. I'm not sure about the > way back. Maybe a function like "decapsule(cap, description)" would work here? > > As for ctypes, we might get away with providing a generic <ctypes> cast and > do the type matching ourselves for the forward way. For the way back into > Cython types, however, we should require an explicitly typed ctypes > variable. Just allowing a cast from anything to a Cython C type would let > our type conversion code explode. > > Not sure how much work it would be to implement this, though. The way from > Cython to ctypes may just be a simple mapping of type names, whereas the > other way might require some utility code overhead. > > Stefan > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
