[Cython] Auto-generation of wrapper types

[da-woods]

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