Port Field to Rust#19143
Conversation
stuhood
added
the
category:internal
stuhood
force-pushed
the
stuhood/field-to-rust
branch
3 times, most recently
from
bd168c2 to
000f6af
Compare
Eric-Arellano
left a comment
Eric-Arellano
left a comment
There was a problem hiding this comment.
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? |
thejcannon
left a comment
thejcannon
left a comment
There was a problem hiding this comment.
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.
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.
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.
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.
What were the errors? That's concerning...
There was a problem hiding this comment.
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.
|
|
||
| # Ensure the field is frozen. | ||
| with pytest.raises(FrozenInstanceError): | ||
| with pytest.raises(AttributeError): |
stuhood
force-pushed
the
stuhood/field-to-rust
branch
from
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. |
stuhood
force-pushed
the
stuhood/field-to-rust
branch
from
8b22bb6 to
1c16922
Compare
| // TODO: Should be `RequiredFieldMissingException`. | ||
| Err(PyValueError::new_err(format!( |
There was a problem hiding this comment.
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.
5 participants
This change ports
Fieldto Rust.One important takeaway was that
pyo3gives us less of an advantage when subclassing is in use, because most methods of the class need to accept themselves asPyCellorPyRef(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 viapyo3as well.Despite that, I'll likely still port
Targetto Rust for consistency, and because it has some longer methods which I expect to see actual performance benefit from porting.