Cython和重载的c ++构造函数

Question

是否有一种标准化（或普遍接受的方式）来解决在包装C ++类时无法在cython中重载__cinit__方法的问题？

有可能使__cinit__取* args和** kwargs包含参数，并在__cinit__范围内选择根据特定模式生成C ++实例的方法。然而，这种方法有并发症：

• 尝试从参数中识别正确的构造函数在某些情况下可能是危险的，除非参数被命名并作为kwargs传递，这可能会对用户造成麻烦。
• 如果参数未在__cinit__参数列表中按类型调用，则它们将作为Python对象传递。在我的工作案例中，参数是C ++类的Python包装器，并尝试检索这些实例“thisptr”是魔鬼的任务，当它们作为Python对象从* args或** kwargs传递时。
• 使用if ... elif ... else序列从参数组合中选择C ++构造函数的隐含需求最终会变得非常混乱。

所以必须有更好的方法。一种方法可能是使用classmethod方法（例如参见：classmethod to overload __init__ behavior in Python）。尽管如此，据我所知（如果我错了请纠正我），classmethod意味着调用名称与类名不同的方法，这与C ++只用一个类名构造实例的方式不太相似。

有关于此的任何想法吗？

Answer 1

就个人而言，我会使用classmethods。

WrapperClass.fromSpambar(spambar)

这不是puzzlin imho 。如果您无法在C ++中重载函数，那么您也需要回退到这种方法。

如果您可以在初始化时接受一些重加权操作，您可以通过定义“模式”或类似方法来实现一种方法来识别构造函数的调用方式。即args和kwargs的正则表达式。 ;）

我没有看到从Python对象获取 thisptr 的问题。

cdef WrapperClass wrpclsi
if isinstance(instance, WrapperClass):
    wrpclsi = instance
else:
    raise TypeError('expected instance of WrapperClass.')

cdef WrappedClassFromCpp* thisptr = wrpclsi.thisptr