-
Notifications
You must be signed in to change notification settings - Fork 290
tidy up tagged_union_schema
#1333
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
Conversation
CodSpeed Performance ReportMerging #1333 will not alter performanceComparing Summary
|
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.
This generally looks good - let's chat about a few questions in our upcoming call - I mostly just have some questions about rust
syntax :).
@@ -71,7 +70,7 @@ impl<T: Debug> LiteralLookup<T> { | |||
.map_err(|_| py_schema_error_type!("error extracting str {:?}", k))?; | |||
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)); |
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.
Just trying to learn more about rust syntax here - could you explain this as_unbound.clone_ref(py)
? Thanks!
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.
As discussed offline - is PyO3 code to change from Bound<'py, PyAny>
to 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.
Nice. I'll approve!
@@ -35,7 +34,7 @@ pub struct LiteralLookup<T: Debug> { | |||
// Catch all for hashable types like Enum and bytes (the latter only because it is seldom used) | |||
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)>>, |
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'm assuming this might be more performant - are there any benchmarks that reflect that?
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.
No benchmarks, but otherwise yes, we don't need to make Python FFI calls here to maintain this internal state :)
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.
Great, thanks for walking me through some of the changes here!
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 toAny
.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.