[Cython] Auto-generation of wrapper types

[Robert Bradshaw]

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-git at 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 at python.org
> > https://mail.python.org/mailman/listinfo/cython-devel
>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel