Skip to content
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

RFC: Type checking in CI and development #1201

Open
Nytelife26 opened this issue Jul 11, 2021 · 3 comments
Open

RFC: Type checking in CI and development #1201

Nytelife26 opened this issue Jul 11, 2021 · 3 comments
Labels
cat: rfc Issues that propose changes, or a Request For Comments. priority: medium Issues and PRs that should be resolved soon. status: needs-help Issues and PRs that require volunteer assistance to proceed. type: ci Issues and PRs related to continuous integration.

Comments

@Nytelife26
Copy link
Member

Nytelife26 commented Jul 11, 2021

Rationale

Type checking in CI and development would ensure that our code runs with minimal runtime errors related to dynamic typing. It would also make it easier to do things like creating configuration structures that are statically typed.

Drawbacks

  • Many Python developers are not used to type hinting and may be confused by it | Resolved by @carlsmedstad's comment
  • It will add time to CI
  • Imports get messy and add runtime weight - any amount of generics, unions, etc, must be imported

The comment that lead to this issue.

This coupled with using mypy

I use pyright locally as it is much more complete and flexible than mypy - I hadn't thought much about including it in CI, as Python tends to not be type-checked much if at all (given its nature as a dynamically typed language) and many people are not used to it, but I can open an RFC issue for that.

Originally posted by @Nytelife26 in this comment on #1200

@Nytelife26 Nytelife26 added cat: rfc Issues that propose changes, or a Request For Comments. priority: medium Issues and PRs that should be resolved soon. status: needs-help Issues and PRs that require volunteer assistance to proceed. type: ci Issues and PRs related to continuous integration. labels Jul 11, 2021
@carlsmedstad
Copy link
Contributor

carlsmedstad commented Jul 11, 2021

My input on this:

Many Python developers are not used to type hinting and may be confused by it

My feeling is that a lot of Python projects are moving to partly or fully typed code-bases and that this is the future of Python. While it might be new to some developers, it makes the code so much more self-documenting that I think it is a net-positive in terms of how approachable the project is.

Where I work we use exclusively fully-typed Python, which is achieved by running mypy in the CI with the following config:

[mypy]
ignore_missing_imports = True
warn_redundant_casts = True
warn_unused_ignores = True
disallow_incomplete_defs = True
disallow_untyped_defs = True
disallow_untyped_calls = True

@Nytelife26
Copy link
Member Author

You have a good point. In addition, doing this will let more people learn about type hinting. Even TypeScript as the evolutionary stage of JavaScript is showing a move from dynamically typed languages in favour of ones that allow strong typing.

I believe pyright would be the better tool to use, as it is significantly faster than mypy and more featured. That leads me to another drawback of typing in Python at its current state, though, which I will mention in the issue.

@Nytelife26
Copy link
Member Author

@suchow Thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat: rfc Issues that propose changes, or a Request For Comments. priority: medium Issues and PRs that should be resolved soon. status: needs-help Issues and PRs that require volunteer assistance to proceed. type: ci Issues and PRs related to continuous integration.
Projects
None yet
Development

No branches or pull requests

2 participants