Add type checker#3116
Conversation
…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. |
|
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 <[email protected]>
Co-authored-by: Emídio Neto <[email protected]>
|
@Kludex - This change prevents mypy from running on users of the opentelemetry-instrumentation-threading library with the follow error: This is a serious problem for my project as convincing mypy not to check this file is difficult bordering on impossible. |
6 participants
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-> Noneon 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.