Verbose Information on TypeError runtime crashes?

Thank you for pyo3.

Using pyo3, when my python code sends the wrong shape (can typically happen given python's dynamic typing during any development work) I get a python backtrace going down to my line of code calling into my rust, and a text error description like:

TypeError: 'float64' object cannot be converted to 'PyArray<T, D>'

Is there a more verbose mode to pyo3 runtime for cases like this?

Of course if my dev workflow is linear enough, I know I should check my types at that line and have good context in mind for quickly resolving it even without re-running with try-except for logging more details.

However it would be nice to have more information already in the error description if possible:

• What are the type values of T and D?
• Which function argument is the error arising for?

Of course, user code can always try-except the offending python call and we can work to reproduce that crash in repeat runs, even if it's outside the development cycle. But having more information by default provides more peace of mind knowing that before you have managed to reproduce you have some more details than the line of user code. All-in-all this is an enhancement which some may object if it adds runtime cost, especially for release builds.

Consider that when we expose rust code to python, some python developers would much appreciate knowing more about the expected types than those developers who understand pyo3 or can directly work with the rust code.

No files, tests, or entry points are named. Start by locating where the PyArray conversion TypeError text is produced, then determine whether type parameters and argument names are available there; done would mean a defined, tested approach for providing the requested additional context without an unspecified runtime cost.