-
Notifications
You must be signed in to change notification settings - Fork 763
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
Migrate PyTuple
/ PyList
constructors
#4580
Conversation
dd87350
to
76f2250
Compare
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, it seems like the correct conclusion to me that the constructors have to become fallible, even it's a small breaking change.
We should mention this explicitly in its own newsfragment, I think.
Makes sense 👍 |
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, looks perfect! 🚀
Just a couple of tiny thoughts.
src/types/list.rs
Outdated
type Error = Infallible; | ||
|
||
fn into_pyobject(self, py: Python<'py>) -> Result<Self::Output, Self::Error> { | ||
self.clone().0.into_pyobject(py) |
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.
I wonder whether it's simpler to remove Clone
from the picture and instead just have the panic produced in here?
IIRC, the main point of the test is to check that panics while constructing the list free stuff properly, Clone
was probably just the bug report which came in or similar.
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.
Yes, I think that makes it a bit clearer. I changed this, removed the now unnecessary cfg
and renamed the test (also for PyTuple
)
src/types/list.rs
Outdated
} | ||
|
||
#[inline] | ||
#[track_caller] | ||
pub(crate) fn try_new_from_iter<'py>( | ||
py: Python<'py>, | ||
elements: &mut dyn ExactSizeIterator<Item = PyResult<PyObject>>, | ||
elements: &mut dyn ExactSizeIterator<Item = PyResult<Bound<'py, PyAny>>>, |
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.
Do you think it's worth making these have a concrete iterator? I forget why we had to change it for sets 🤔
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.
Do you mean impl
instead of dyn
here? Or what concrete type are you referring to?
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.
Yes, impl Iterator
e77511b
to
3eddf7c
Compare
3eddf7c
to
42b6c12
Compare
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.
Super, thanks 👍
I'll seek to get to the other reviews waiting on me either tonight or tomorrow evening
Followup to #4559
PyList::new
andPyTuple::new
become fallible.It's worth double checking the
bad_clone_mem_leaks
tests, to make sure I didn't accidentally change the semantics there.