Currently pyarray and pytensor constructors can throw exceptions when constructed from a pyobject (in case of bad layout or incorrect dimension for pytensor). This can stop pybind11 overload resolution mechanism, hence leading to a failed function call while possible valid other overloads exist.
For example, if we have two overloaded definitions of the foo function, one taking a 1d pytensor and the other taking a 2d pytensor:
m.def("foo", [](xt::pytensor<int, 1> a) { return 1; });
m.def("foo", [](xt::pytensor<int, 2> a) { return 2; });
trying to call:
foo(np.ones((2,2), dtype=np.int32)
will produce a runtime error ("NumPy: ndarray has incorrect number of dimensions") instead of using the second definition of foo.
A possible solution could be to swallow exception in pytensor and pyarray type casters and simply return false (cast has failed) to let pybind11 continue its job. However this solution would remove precious debugging information for end-users to understand why some function call fails.
Currently
pyarrayandpytensorconstructors can throw exceptions when constructed from apyobject(in case of bad layout or incorrect dimension forpytensor). This can stop pybind11 overload resolution mechanism, hence leading to a failed function call while possible valid other overloads exist.For example, if we have two overloaded definitions of the
foofunction, one taking a 1d pytensor and the other taking a 2d pytensor:trying to call:
will produce a runtime error ("NumPy: ndarray has incorrect number of dimensions") instead of using the second definition of
foo.A possible solution could be to swallow exception in
pytensorandpyarraytype casters and simply returnfalse(cast has failed) to let pybind11 continue its job. However this solution would remove precious debugging information for end-users to understand why some function call fails.