Skip to content
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

Open
davidhewitt opened this issue Jun 11, 2023 · 4 comments
Open

Review conversions and ensure consistency #3226

davidhewitt opened this issue Jun 11, 2023 · 4 comments

Comments

@davidhewitt
Copy link
Member

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 for bool, 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).

@yusharth
Copy link

Can I take it?

@davidhewitt
Copy link
Member Author

Sure thing, please do! Is there any extra information you need to get started?

@mikeleppane
Copy link

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.

@davidhewitt
Copy link
Member Author

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 tables.md as I wrote in the original post above.

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 #[pyo3(noconvert)] in that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants