I am in general of more automated wrapping. Two things that make C++ classes more difficulty are.
(1) How to handle inheritance (including multiple inheritance)? Would the wrapped types mirror the inheritance? (2) We can do auto-conversion of most types because they are passed by value. This breaks down a bit with char*, but generally we assume we can take a copy. Similarly with structs. However C++ classes are (in practice) much more stateful and this gets into all sorts of thorny issues with what the conventions should be about ownership and common references. There's also a fair number of existing libraries out there that specifically target wrapping C++ libraries (often directly from the source files). As well as making it easier to wrap from C++ classes from Cython, it'd be good to have more seamless (and efficient) integration with those. On Sun, Mar 15, 2020 at 1:34 PM da-woods <dw-...@d-woods.co.uk> wrote: > > On 15/03/2020 08:14, Stefan Behnel wrote: > > What makes C structs and C++ classes special enough to make this a separate > > language feature? That should be part of a motivation somewhere (probably > > in a ticket > > Most of the other major things you could want to wrap are covered > through other mechanisms - you can create a wrapper round a `cdef > extern` function or enum with `cpdef`. The basic C types (int, float) > etc largely have a direct Python equivalent that converts freely. > > This is mainly targetted at C++ classes which seem to be the last major > feature that doesn't have this kind of wrapper. C structs just seemed > easy to deal with by the same mechanism - although they obviously have > the conversion to/from dict, which is fine but does involve a > conversion, and so doesn't propagate modifications back. > > I'll create a ticket fairly shortly. > > > How does this relate to the support for @dataclass in GH-2903? Is the only > > difference that you would write "x.member" instead of "x.structattr.member"? > > It's slightly difficult to answer that because we don't know exactly > what @dataclass will look like in Cython. In Python it's mostly about > generating `__init__`, `__repr__`, `__eq__` etc from a "struct-like" > description. The Cython version I've submitted basically just follows > the Python scheme, but it isn't obvious how Python-level access to > attributes should work. "x.structattr" would probably end up doing the > usual Cython conversion to/from a dict. > > This feature is mostly for creating a quick wrapper for some external > C/C++ thing that already exists. For a struct it probably isn't too > different from a dataclass. For a C++ class it should hopefully be able > to fill in a lot of the functions too. > > > Why "autowrap[S]" and not "autowrap(S)"? I'm asking also because there > > should probably be a way for this to work in Python files, for which a > > function call seems more natural. > > > > It also feels like a @decorator would somehow fit quite well here. Even > > when defined in a .pxd file, the struct would still only be exported in the > > corresponding module (with the same name). Something like this: > > > > @cclass > > cdef struct S: > > int x > > > > Not sure if reusing @cclass is a good idea, but it doesn't seem wrong. > > Definitely open to different syntax - now you point it out I think a > function call might be better than an index (especially with optional > keyword arguments to control it). > > One other option (for consistency with how functions/enums are already > handled) would be `cpdef struct S/cpdef cppclass ClassName`. The > difficulty here is that it overrides the name which I suspect could be a > challenge (in most cases you'd probably want to access the original > definition and the wrapper extension type separately in Cython). This > might be an issue with a decorator too. > > > Defining this in a .pxd file could then even allow cimporting modules to > > understand the extension type wrapper as well, by simply reconstructing the > > type representation on their side. > > I hadn't thought of this, but yes. This should be pretty simple - the > type representation is really just: > > cdef class SomeName: > cdef c_type* obj > @staticmethod > cdef factor_func(obj x) # possibly reference or r-value here > reference.... > > (Almost) everything else it defines is a Python interface of def > functions and properties so a cimporting module would have no special > knowledge - for fast access the user would go through obj. > > David > > > > > > Stefan > > _______________________________________________ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
