pytest-html
pytest-html copied to clipboard
pytest-dev
Add mypy to CI pipeline and begin typing modules
Begin the mypy/typing addition as outlined in https://github.com/pytest-dev/pytest-html/issues/434 by incorporating mypy and typing:
__init__.pyextras.pyoutcome.pyutil.py
The rest of the files will be typed in follow up PRs to not have to submit one large PR.
The mypy config was started by taking that of pytest's and then being a little stricter on untyped/incomplete function definitions and calls. You can see the full list of config options here, but I think this is a good enough starting point.
Something that worries me a little bit, is that we might be raising the bar/entry for contributors by using typing. 🤔
Something that worries me a little bit, is that we might be raising the bar/entry for contributors by using typing. 🤔
Why do you say that? If anything I'd say it lowers the bar since people know the type of arguments immediately on reading the code and no longer have to guess at what's going on with types
Besides, it's becoming more common practice to type Python
Something that worries me a little bit, is that we might be raising the bar/entry for contributors by using typing. 🤔
Why do you say that? If anything I'd say it lowers the bar since people know the type of arguments immediately on reading the code and no longer have to guess at what's going on with types
Besides, it's becoming more common practice to type Python
You pretty much answered your own question:
people know the type of arguments immediately on reading the code
Besides, it's becoming more common practice to type Python
Yes, it's becoming more common, but far from the norm yet, and to be able to read it - they have to first understand it, otherwise it's just noise that often can lead to hard to understand errors. Especially for more complex types.
It's just the typing library, and you only have complex types if you introduce them.
In my personal experience I don't think it'll complicate things. Most people are used to types (c++, Java, etc.) and the types are named almost identically to the Python objects they represent.
The only issue I can see is someone having a hard time guessing what type something is when writing new code, but I would say that the author should fully understand what they're implementing in that case before they implement it.
