-
Notifications
You must be signed in to change notification settings - Fork 770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More verbose conversion/downcasting errors. #652
Comments
Looks nice 👍 |
I was looking at the code generation yesterday and it would be possible to be verbose there, but not in a clean way: Either the (possibly in Another option could be changing the conversion impls in /// Allows extracting strings from Python objects.
/// Accepts Python `str` and `unicode` objects.
impl<'a> crate::FromPyObject<'a> for &'a str {
fn extract(ob: &'a PyAny) -> PyResult<Self> {
let s: Cow<'a, str> = crate::FromPyObject::extract(ob).map_err(|_| {
TypeError::py_err(format!(
"Failed to extract string from {}",
ob.get_type().name()
))
})?;
match s {
Cow::Borrowed(r) => Ok(r),
Cow::Owned(r) => {
let r = ob.py().register_any(r);
Ok(r.as_str())
}
}
}
} As a workaround within my own project, this little helper method comes in handy: pub(crate) fn t_from_any<'a, T>(any: &'a PyAny, to: Option<&str>) -> PyResult<T>
where
T: FromPyObject<'a>,
{
let any_type = any.get_type().name();
let msg = to
.map(|to| format!("Expected '{}' not '{}'", to, any_type))
.unwrap_or_else(|| format!("Invalid argument: '{}'", any_type));
any.extract::<T>().map_err(|_| type_err(msg))
} |
This would be a really useful feature. It would would also be good to include the name of the argument that has the wrong type. E.g. right now you get this:
What I would like to happen is something more like this:
|
I'd like to take a look at some form of this for |
Closed via #1050 |
pyo3 tries to convert arguments to the specified type in the signature, if that fails it returns
TypeError
without any message through:Since conversion happens before entering the user-defined method body, there's no way to be verbose about what happened unless some new-type is defined for which
extract()
is implemented manually or the method is changed to take&PyAny
orPyObject
to begin with - which also entails manual extraction.Are there obvious downsides to changing
PyDowncastError
to wrap a String holding an error message that gets propagated into Python?In that case, the failed conversions could return something along these lines:
The text was updated successfully, but these errors were encountered: