-
Notifications
You must be signed in to change notification settings - Fork 33
Static typing #199
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
base: master
Are you sure you want to change the base?
Static typing #199
Conversation
this is needed for static typing support
|
ready for review :) |
|
I moved the CLI logic into a new |
|
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? |
Somewhere between 50 and 200 ms startup time, mostly because of the additional imports. |
|
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. |
|
How about I open another PR with inline annotations so we can compare the two? Edit: #200 |
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.