-
Notifications
You must be signed in to change notification settings - Fork 3
refactor: [typing] add typing to the Scheduler #32
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
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.
Lots of nitty comments, but I love the way types are getting into the core code.
item._create_deploy_objects() | ||
|
||
def deploy_objects(self): | ||
def deploy_objects(self) -> Mapping[Deploy, str]: |
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.
Definitely not for this PR (but I was reading this file...) I wonder whether this function name needs to be changed to something like get_deploy_objects
or maybe whether it should be turned into a property?
At the moment, it's a bit sad that "deploy" is a verb as well as an adjective.
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.
Yes makes sense, I'd like to eventually refactor the whole thing with tests.
src/dvsim/scheduler.py
Outdated
msg = f"Scheduler does not contain target {curr_target}" | ||
raise KeyError(msg) |
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 big deal, but why not stick the string literal directly into the KeyError
call?
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.
Because of the lint rule that complains about having f-string directly in an Exception
. I've disabled the one that prevents string literals, so if it wasn't a f-string then it would not complain about it.
I don't have a strong opinion either way really. It does slightly clean up the stack trace to have the intermediate variable. But makes the code base slightly more messy.
0217eef
to
d6f3d8a
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.
LGTM! Great progress so far.
Types added to make it clearer what is going on with the job scheduling. This means the pyright/ruff LSP have more information to be able to jump to definitions and show documentation. Signed-off-by: James McCorrie <[email protected]>
Types added to make it clearer what is going on with the job scheduling. This means the pyright/ruff LSP have more information to be able to jump to definitions and show documentation.