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
