-
-
Notifications
You must be signed in to change notification settings - Fork 605
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
Integrate the native options parser into Python. #20887
Conversation
Note that this is categorized as a new feature because we do want it to be mentioned in the changelog. |
rust_option_type = option_type | ||
rust_member_type = member_type | ||
|
||
if option_type is dict: |
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.
Below is a bunch of munging to massage the raw rust values into their expected Python types.
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.
It looks like there's some pretty... intricate processing here with the eval
calls and the shlex.split
ing.
Might we ever end up with fully Rust-side manipulation of options, or would we expecting to always go back out through Python for these sort of adjustments? If the first one, is there a path for moving more of this logic into Rust too?
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.
Yeah, this mostly emulates what happens in the native parser, which unfortunately supports all sorts of clever types, expressed as a str -> type cast.
I don't yet know which of these will make sense to represent in Rust. At a guess, I'd say shell_str and path yes, but targets no?
Anyway, I think this will be best revisited after we get rid of the legacy parser. Then we can do more chipping away at the Python side of things once a whole ton of that cruft is gone.
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.
So good, really nice to be running them in parallel 👍
rust_option_type = option_type | ||
rust_member_type = member_type | ||
|
||
if option_type is dict: |
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.
It looks like there's some pretty... intricate processing here with the eval
calls and the shlex.split
ing.
Might we ever end up with fully Rust-side manipulation of options, or would we expecting to always go back out through Python for these sort of adjustments? If the first one, is there a path for moving more of this logic into Rust too?
Also, when you have a chance, please merge |
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.
Looks great, other than the notes movement & text addition!
This change:
A) Provides Python bindings to the Rust options parser.
B) Integrates the Rust options parser into the options parsing flow.
Currently, the existing legacy parser and the native parser are
both consulted, and their results compared, with discrepancies
logged. This will allow us to evaluate and fix such discrepancies
during a transition period.