[th/mypy] fix typing annotations so that mypy --strict passes and enable github action
#24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The pattern
out = proc.stdout.read().decode("utf-8")
err = proc.stderr.read().decode("utf-8")
is broken, because we won't read stderr before stdout is fully read.
That means, if the command writes a lot to stderr, then the pipe will
block writing and hang the process.
Use subprocess.run(), which gets this right.
With namedtuple, mypy doesn't understand the types of the fields. Use a dataclass instead.
This is copied over from common_bf.run(). The difference is that it better handles typing. Later, we should not copy code around but re-use code (e.g. by importing the common_bf module). But for now, it is still copied because to import the code we also need to ensure that we include the common_bf module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
common_bf.run()needs to switch from aResultnamedtuple to a dataclass. The reason is, that with dataclasses mypy understands the types (alternatively, we could usetyping.NamedTuple, but a dataclass works well).common_bf.run(), also switch it over tosubprocess.run(). The reimplementation withPopen()was not correct (because it reads stdout to the end, if a process prints a lot to stderr, it will block).common_bf.run()over todpu-tools.run(). It's the same thing (also needing changes to work with mypy checks), and should use the same code.