-
-
Notifications
You must be signed in to change notification settings - Fork 651
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
Port Field
to Rust
#19143
Port Field
to Rust
#19143
Conversation
bd168c2
to
000f6af
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! Any benefit to porting the Field subclasses like BoolField?
Possibly, but not in the interest of making porting |
Friendly ping. |
I'll take a look ASAP, although @huonw might have better review goggles than the Joshs 😄 Any back-of-the-envelope perf numbers to share? |
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 didn't look too closely at the Rust code. I figure the perf has to be better just from porting. And if the tests pass that's a good indicator of code soundness.
# Type alias to express the intent that the type should be immutable and hashable. There's nothing | ||
# to actually enforce this, outside of convention. | ||
ImmutableValue = Any |
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.
FYI The Python std library (and therefore core devs) have roughly said that hashability implies immutability. Search https://docs.python.org/3/library/dataclasses.html for "mutability".
So in that regard, this could be an alias for typing.Hashable
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.
That's potentially backwards incompatible... but assuming that mypy
doesn't misbehave, it should only catch bugs? Will try it.
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.
That causes a number of type checking errors in our code (and more in user code most likely): will save for another change.
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.
What were the errors? That's concerning...
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 didn't look into it, but there were at least 10.
My goal with these port PRs is not to change behavior (unless it makes it easier to accomplish them), since my feeling right now is that getting out of our performance hole is the most important goal.
with pytest.raises(FrozenInstanceError): | ||
with pytest.raises(AttributeError): |
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.
oh bummer...
000f6af
to
8b22bb6
Compare
No, haven't done any benchmarking... I'm really not expecting anything here though, given how tiny the various functions were. |
(FYI force-pushing means I can't review just what's changed since my last review. Usually in order to not overwhelm myself I trust past-Josh's review of the code and just review the diff. In this instance I have no clue what changed since the last review 😢 ) |
Nothing has changed since your last review (for the reasons in the threads): if anything had, I would have created a separate commit. |
8b22bb6
to
1c16922
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.
Nice!
// TODO: Should be `RequiredFieldMissingException`. | ||
Err(PyValueError::new_err(format!( |
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.
Is using an error defined in python more difficult than using the built in errors? This is the only conerning thing I see in this PR (from my post-review merge). Very cool stuff!
### Internal * upgrade to Rust v1.70.0 ([#19228](#19228)) * Remove the last mentions of NO_TOOL_LOCKFILE. ([#19229](#19229)) * Upgrade Helm unittest ([#19220](#19220)) * Prepare `2.17.0rc0`. ([#19226](#19226)) * Use a trait for remote action result caching ([#19097](#19097)) * Port `Field` to Rust ([#19143](#19143)) * Upgrade `pyo3` to `0.19`. ([#19223](#19223)) * Prepare `2.16.0rc5`. ([#19221](#19221)) * internal: Create dep inference request type ([#19001](#19001)) * Avoid requiring Python when trying to install Python (using Pyenv) ([#19208](#19208)) * Fix secondary ownership warning semantics ([#19191](#19191)) * Bump os_pipe from 1.1.3 to 1.1.4 in /src/rust/engine ([#19202](#19202)) * Include committer date in local version identifier of unstable builds ([#19179](#19179)) * Ensure we set the AWS region. ([#19178](#19178))
Field construction was ported to Rust in #19143, which incidentally broke the field deprecation check. As a result, a deprecation warning was emitted even if the user was not setting the field explicitly.
This change ports
Field
to Rust.One important takeaway was that
pyo3
gives us less of an advantage when subclassing is in use, because most methods of the class need to accept themselves asPyCell
orPyRef
(in order to gain access to their subclass instance, which isn't a member of the wrapped struct). Those methods can then only be called viapyo3
as well.Despite that, I'll likely still port
Target
to Rust for consistency, and because it has some longer methods which I expect to see actual performance benefit from porting.