Currently, cppyy.gbl.eantic.renf_elem_class is not functional when called from Python. (See e.g. the special handling of e-antic in flatsurf's surfaces.py.)
At the moment, we work around this problem by exposing a factory function renf_elem that creates a renf_elem_class. However, this has limitations, e.g., when the type is coming from elsewhere say when it is flatsurf::Vector<eantic::renf_elem_class>::Coordinate.
It would be great if we could wrap the actual constructor of renf_elem_class instead so that the type can be used transparently.
Dependencies
Currently,
cppyy.gbl.eantic.renf_elem_classis not functional when called from Python. (See e.g. the special handling of e-antic in flatsurf's surfaces.py.)At the moment, we work around this problem by exposing a factory function
renf_elemthat creates arenf_elem_class. However, this has limitations, e.g., when the type is coming from elsewhere say when it isflatsurf::Vector<eantic::renf_elem_class>::Coordinate.It would be great if we could wrap the actual constructor of
renf_elem_classinstead so that the type can be used transparently.Dependencies
make_renf_elem_classuntil https://bitbucket.org/wlav/cppyy/issues/376/stack-overflow-when-calling-private has been resolved.