-
Notifications
You must be signed in to change notification settings - Fork 778
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
Review conversions and ensure consistency #3226
Comments
Can I take it? |
Sure thing, please do! Is there any extra information you need to get started? |
Hey! If this is still open and something that requires improvement, I would be interested to a take look. Hopefully, I could contribute more in the future. |
Hello, thank you for your interest! Yes, this is absolutely still open to improvement. First, I'd suggest starting with updating the conversions documentation in Second, if you're interested in going beyond collecting what's currently implemented to make things better, I think we would like to go down the path of having "default" conversions which allow a range of inputs and also a user-facing attribute to control when they want exactly a specified type. I wrote about this topic most recently in #3638 (comment) We called the option |
Continued from #3197 (comment)
We would like to ensure that we're consistent in how conversions from Python objects to Rust objects select for what's allowed.
I think the right approach would be to do something like https://github.com/PyO3/pyo3/blob/main/guide/src/conversions/tables.md where for each Rust type we state what Python types will convert to it (i.e.
FromPyObject
), and what Python type(s) it will convert back into (i.e.IntoPy<PyObject>
).That information does live on that page, but perhaps it can benefit from being rearranged.
In general we seem to be preferring conversions which are allow the user to be a bit loose with typing (e.g. string for IP address). So I think we should ensure we stick to this philosophy everywhere (e.g. maybe we should accept
int
forbool
, or even all truthy types)?We may also wish to consider a "strict" mode where only the exact Python type can be input (e.g. Python bool <-> Rust bool).
The text was updated successfully, but these errors were encountered: