Skip to content

Conversation

@clin1234
Copy link
Contributor

No description provided.

Copy link
Owner

@indygreg indygreg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't realize that this migration would be this simple!

If we change .unwrap() to ?, this diff seems reasonable to me.

Rebase it and let's get it merged!


Ok(Self {
source: data.into_py(py),
source: data.into_py_any(py).unwrap(),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be .into_py_any(py)?

Copy link
Contributor Author

@clin1234 clin1234 Aug 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fn into_py_any(self, py: Python<'py>)

returns PyResult<Py<PyAny>>, which is defined as a Result type. Since the previous into_py returned a bare PyObject without any checks for the Err result, the unwrap() seems fine.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use ? out of principle. The unwrap() forces people to reason about its existence which just adds to the maintenance burden.

Copy link
Owner

@indygreg indygreg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great to me!

Unless you have objections, I'll merge this once CI comes back clean.

@indygreg indygreg closed this in 6753396 Aug 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants