Skip to content

Conversation

davidhewitt
Copy link
Contributor

Closes #925

While checking out the suggested type hints there and comparing to the implementation, I saw that we stick all unhashable discriminants in a list and to equality comparison on them. So I decided to keep things simple and relax the Hashable bound to Any.

At the same time, I saw that the list was not necessary and we could use a Rust Vec. So I simplified the implementation a little.

Copy link

codspeed-hq bot commented Jun 17, 2024

CodSpeed Performance Report

Merging #1333 will not alter performance

Comparing dh/tagged-union-tidy (e163983) with main (9507a28)

Summary

✅ 155 untouched benchmarks

Copy link
Contributor

@sydney-runkle sydney-runkle left a comment

Choose a reason for hiding this comment

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

This generally looks good - let's chat about a few questions in our upcoming call - I mostly just have some questions about rust syntax :).

expected_str.insert(str.to_string(), id);
} else if expected_py_dict.set_item(&k, id).is_err() {
expected_py_list.append((&k, id))?;
expected_py_values.push((k.as_unbound().clone_ref(py), id));
Copy link
Contributor

Choose a reason for hiding this comment

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

Just trying to learn more about rust syntax here - could you explain this as_unbound.clone_ref(py)? Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As discussed offline - is PyO3 code to change from Bound<'py, PyAny> to Py<PyAny>.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice. I'll approve!

expected_py_dict: Option<Py<PyDict>>,
// Catch all for unhashable types like list
expected_py_list: Option<Py<PyList>>,
expected_py_values: Option<Vec<(Py<PyAny>, usize)>>,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm assuming this might be more performant - are there any benchmarks that reflect that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No benchmarks, but otherwise yes, we don't need to make Python FFI calls here to maintain this internal state :)

Copy link
Contributor

@sydney-runkle sydney-runkle left a comment

Choose a reason for hiding this comment

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

Great, thanks for walking me through some of the changes here!

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

Labels

None yet

2 participants