Verbose Information on TypeError runtime crashes?

未指定文件、测试或入口点。首先定位生成 PyArray 转换 TypeError 文本的位置，然后确定类型参数和参数名称在那里是否可用；完成的标准是有一种已定义且经过测试的方法，能够在不产生未指定的运行时开销的情况下提供所请求的额外上下文。

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.