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
Initial mypy implementation #405
base: main
Are you sure you want to change the base?
Initial mypy implementation #405
Changes from all commits
f544a68
315a294
5bc4ccd
841aca7
43b27f8
1b7ed32
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 have another comment related to this file and our typing "completeness". I had been looking for some specification on what makes a
py.typed
library, and didn't find it until last night in thetyping.readthedocs.io
docs. What stuck out to me is the examples in "Examples of known and unknown types":I don't think we have enough of
ocs
typed in this PR to claim it's apy.typed
package.There are some interesting discussions on the
python/typing
repo, especially this one on how to gradually type a library. It seems like type stubs can be partial, and marked as such by containingpartial\n
. I haven't seen anywhere that says this is valid for a package with inline type hinting though.We have a pretty limited downstream user base, but what is the implication for typing efforts in
socs
if we don't includepy.typed
here inocs
yet?Thoughts on more thoroughly typing
I also found this discussion about how typing simple examples like:
as
feels redundant. The response to that post comes from one of the maintainers of pyright, Microsoft's static type checker -- this seems to be the core for Pylance, the default LSP for VS Code. There I learned about
pyright --verifytypes
, which can be used to check the "completeness" of apy.typed
package.Running that we score a 17.3% in this branch currently.
Thinking about our approach to enforcing PEP8 through
autopep8
, I wondered if there were automated ways to annotate these obvious types. I found a list of tools in the mypy docs. They seem to only focus on function arguments and return values, but they get us a bit closer.On top of that, a lot of the modules in
ocs
should really probably be private (pyright only reports missing types for public modules), as ocs plugin authors shouldn't be importing code from core agents, nor any of the "scripts" likeagent_cli.py
. If I mark modules that probably should be private as such and run one of the autotyping tools we get up to 22.4%, with 175 "unknown" types and 15 "ambiguous" types out of 245 symbols exported byocs
.