-
Notifications
You must be signed in to change notification settings - Fork 641
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
Add type checker #3116
Add type checker #3116
Conversation
...ntelemetry-instrumentation-threading/src/opentelemetry/instrumentation/threading/__init__.py
Outdated
Show resolved
Hide resolved
…thon-contrib into add-type-checker
I don't have any preference but I think you missed that we are using mypy in opentelemetry-python |
I was checking opentelemetry-python, and it seems that pyright is also present there? A bit more into it... Seems like if |
I took some time trying to set up mypy to see how that would look like, and it just took too much of my time, and I was not able to make it work properly... I'm happy to close this if people are strong on mypy, but I'm not willing to spend more time trying it. |
I think the mypy setup on It would be great if people could share opinions on this, I want to continue adding type hints, but without regressions. |
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.
Thanks. Discussed this at SIG (01/09) and agreed to move forward with pyright in contrib and include some packages to be typechecked. After that, also adopt pyright in core as well.
nit: can we include the packages you've added type hints?
Not yet, cause I've mainly added type hints on public APIs. I need to add more stuff to them that I was not very strict. |
Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com>
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.
Very exciting, thank you!
Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com>
This PR adds type checker to
tox
.PyRight Vs MyPy
There's a lot of discussion around about which one to use. I don't think it matters much which one to choose. There are points where Python itself is not specific, and then the type checkers have freedom to choose the behavior they want... Example:
mypy
: On strict mode, you need to add-> None
on the return statement.pyright
: infers that isNone
, so you don't need to add-> None
.PyRight is easier for VSCode users, me included... 👀
About the ecosystem... I think most of them use mypy, but Pydantic for example, uses PyRight.
If you look at the projects I maintain (starlette, uvicorn), I use mypy on them, but I have to say that is a bit more practical to have the type checker match my IDE.
Anyway... I hope this is not an issue, and we can start with this setup.