{{ message }}
Static typing#199
Open
jorenham wants to merge 7 commits into
Open
Conversation
Author
Author
|
I moved the CLI logic into a new |
Contributor
|
Hi, thanks for the PR, and sorry for the late feedback. Personally, I think I would have preferred inline annotations. What is the expected performance difference between the 2 options. @jeremiedbb do you have a preference? |
Author
Somewhere between 50 and 200 ms startup time, mostly because of the additional imports. |
Contributor
|
Since those are all standard libraries imports, I suppose that it will not be noticeable for any Python program that already uses type hints otherwise. No strong opinion either way. |
Author
this is needed for static typing support
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
I noticed that
threadpoolctldid not have static typing support, so I quicky wrote some (non-intrusive) stubs. The.pyistub covers 100% of the public api, and (almost?) everything of the private API.I went with stubs instead of inline annotations because I noticed that performance matters, and inline annotations tend to negatively impact that. Another reason is that I'm (very) used to writing stubs, so I'm pretty biased haha. Note that there some automated tools available that merge
.pyistubs into a.pyas inline annotations.I must admit that I'm not very familiar with the codebase, so there's a chance that I made a small mistake here and there. So please let me know if you see anything questionable. AFAIK it's also fine to commit to this branch yourself.
Mypy's
stubtesttool (the state-of-the art for validating stubs) seems to like it. I added astubtestjob to the CI which will help prevent any regressions.I wasn't able to get
flitto includethreadpoolctl.pyiin the wheel with the original "flat" project layout. So I unfortunately had to change it to a package-based layout. The sdist and wheel are building juist fine, and include the.pyiand thepy.typed. The need for apy.typedis explained at https://typing.python.org/en/latest/spec/distributing.html#packaging-typed-libraries . Note that even if the.pyiannotations were to be inlined in the.py, then you'd still need thepy.typed, because otherwise static type-checkers will simply ignore the annotations. And I don't think that it's possible to package apy.typedif you have a "flat" project layout, but I might be wrong.