Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fixed Typehint for RunSettings.colocated_db_settings #462
Fixed Typehint for RunSettings.colocated_db_settings #462
Changes from 18 commits
f7af9ff
6ca7995
3590d2a
c2b51a3
1f1ebf2
86e1f39
b0ec4a5
3ecec9f
2627516
fad01ca
857b846
28090a3
cbdbe92
6839676
e4146cd
c3e32ff
dfc4e36
242f31a
73495ab
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 96 in smartsim/_core/launcher/step/step.py
smartsim/_core/launcher/step/step.py#L96
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.
Can we change the names of these of these intermediary variables to something a bit more descriptive (maybe
custom_pinning_
andcpus_
)?Or maybe just remove them entirely?
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 would almost suggest keeping the vars for readability, but Im not as experienced so let me know!
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.
Totally willing to keep the intermediate variables! I think I agree that they improve readability!
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.
Minor refactor request here to make sure this is not a breaking API 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.
If Im already casting this to an int, why again?
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.
t.cast
is purely for the type checker while theint
will actually do the cast at runtime. It's HIGHLY unlikely, but there is the possibility that the"db_cpus"
key maps to afloat
(or astr
, or some other type) that can be cast to anint
.so for instance
will run just fine and print
3
while
will raise an
AssertionError
.Just to make sure that this is preserving the original behavior and prevent an API break I would rather just subtly lie to the type checker and let it think that
self.colocated_db_settings.get("db_cpus", 0)
is some type that can be cast to anint
. But do LMK if you think I am being too paranoid!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 see I see, some witchery I would say