-
Notifications
You must be signed in to change notification settings - Fork 802
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
Make #wrap_pyfunction return a Bound value #3808
Closed
+11
−7
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1,10 @@ | ||
use crate::{derive_utils::PyFunctionArguments, types::PyCFunction, PyResult}; | ||
|
||
pub use crate::impl_::pymethods::PyMethodDef; | ||
use crate::Bound; | ||
use crate::{derive_utils::PyFunctionArguments, types::PyCFunction, PyResult}; | ||
|
||
pub fn _wrap_pyfunction<'a>( | ||
method_def: &PyMethodDef, | ||
py_or_module: impl Into<PyFunctionArguments<'a>>, | ||
) -> PyResult<&'a PyCFunction> { | ||
PyCFunction::internal_new(method_def, py_or_module.into()).map(|x| x.into_gil_ref()) | ||
) -> PyResult<Bound<'a, PyCFunction>> { | ||
PyCFunction::internal_new(method_def, py_or_module.into()) | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Maybe here we could just take
fun: impl ToPyObject
? That would avoid breaking existing direct calls, and we plan to remove this function anyway.We could add a note to document the strange generic signature is for backwards compatibility while this API is on its way out.
Might make the implementation a little messier, but I'm sure it could work.
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.
Either way, by changing this function I think we need a
3808.changed.md
newsfragment.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.
impl trait in argument position is a bit of a smell for library API because callers have a hard time defining the implicit type argument (only via casts and and such, potentially requiring a additional closure around the call). But adding a generic argument would strictly speaking not be backwards compatible.
I am not sure yet why we do not just have
add_function
andadd_function_bound
(oradd_bound_function
)?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.
The main problem is what do to with
wrap_pyfunction!
, and whether we want to change it.At the moment we have:
If we don't change
wrap_pyfunction
, and go forwrap_pyfunction_bound
, then we end up with this:Which creates a bigger diff the more functions the user has. I guess it's not too bad, though.
If we change
wrap_pyfunction!
return type like like we changedintern!
, then the only thing users would need to change is the module type:... but maybe we're making this more complicated than it needs to be, and we should just add
wrap_pyfunction_bound
? I guess unlikeintern!
, mostwrap_pyfunction!
calls will all be located in one place in the#[pymodule]
. So it's not a very hard transformation.... @snuderl what do you think of this? I guess adding
wrap_pyfunction_bound!
creates a bigger diff, but maybe it's not too bad?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.
Yeah adding
wrap_pyfunction_bound!
should be pretty trivial it just hopped it could be avoided :)There are 174 usages in the PyO3 repo, I guess we want to switch all of them right?
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.
Thinking about it, probably adding
wrap_pyfunction_bound
gets very messy without the second commit I have in #3744, which allowed&Bound<PyModule>
in#[pymodule]
. Because I think we would want to have havewrap_pyfunction_bound!
used in#[pymodule]
which use&Bound<PyModule>
, and then maybe we keep just one test which uses the deprecated&PyModule
toI really need to tidy that PR up and get it ready for review... 😢