-
Notifications
You must be signed in to change notification settings - Fork 747
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
initial migration of the trait bounds to IntoPyObject
(PyAnyMethods
)
#4480
Conversation
Co-authored-by: Lily Foote <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! I wonder, we see the A::Error: Into<PyErr>
bound so much, should we put that on the trait definition and drop it from everywhere else? At this point it seems to me that any implementation of IntoPyObject
which doesn't support Into<PyErr>
will be nearly unusable.
Yeah, I'm also kind of torn here. Within PyO3 we kind of need this for everything. The only use case I can think of is an error that should specifically not escape into Python and where it might not be possible to move all the error handling into the impl ... But that sounds like a rather niche use case, so maybe it does not warrant the additional complexity of repeating that bound pretty much everywhere. |
Right, but how would that |
Yeah, it could only be used manually on an instance of such a type. I guess there is really no need for that. Moving the bound will make writing generic code much nicer and there is also less surprises for users if they accidentally use an incompatible error type and would get compile error from the macros. I'll make that change and file a PR. |
This starts the migration of the trait bounds to use
IntoPyObject
instead ofIntoPy
/ToPyObject
Test changes:
()
now turning into aPyTuple
both are expected by the new API.
I already added a small migration entry here, we can extend that when we migrate more APIs and implemented #4458. Same with the guide section.
Notable observation: Initially I tried to use
PyErr: From<T::Error>
as a bound on the APIs, but that caused inference issues of the associated type on the call site, so we should probably stick withInto
even tho it's a bit more verbose on the implementation site.