Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign uppyarray and pytensor constructor can break pybind11 overload resolution #178
Comments
|
I just experienced the same issue. Is there a plan to fix it recently? Thanks a lot! Any suggestions on a workaround is also appreciated. |
|
Hi, I remember discussing this on Gitter with probably @wolfv and @JohanMabille . I think that at that time we decided to keep better debugging info for users instead of providing more possibilities for the devs. Maybe, one solution could be to implement the "catch exception" solution and add extra optional debug info at request with a logging tool but I don't remember if there is a standard mechanism for this in xtensor*. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.