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

Mypy compliance / type checking #75

Open
tgross35 opened this issue Jun 11, 2022 · 2 comments
Open

Mypy compliance / type checking #75

tgross35 opened this issue Jun 11, 2022 · 2 comments

Comments

@tgross35
Copy link

Would there be any interest in a PR to add typing for mypy compliance? The main benefits are better IDE integration and improved static type checking on projects that use pytz

Effort is pretty minimal, mypy only raises 14-18 errors currently, depending on the python version.

A stubs repo already does exist: much of that could likely https://github.com/python/typeshed/tree/master/stubs/pytz/pytz

Type hinting is quite easy in python 3.6+. Not sure how long compatibility for python 2.7/3.5 (seen in pipelines) is intended for but that's doable too, just less elegant https://mypy.readthedocs.io/en/stable/cheat_sheet.html

@stub42
Copy link
Owner

stub42 commented Aug 12, 2022

I'm leaning towards a no. We could use the comment syntax, but we won't find out about any problems with peoples legacy build pipelines and deployments for quite some time (because they don't get updated that often). By which time the changes are entrenched. Does embedding the type hints in pytz itself give any material benefits? If the typeshed work allows people to opt in, then keeping it there would be my preference.

@tgross35
Copy link
Author

The main benefit with integrating type hints is user convenience, so users get the correct hints in IDEs/MyPy without needing to install and rely on another (unofficial) package. It's not the biggest deal, but it does count.

I understand reluctance to potentially break py2 environments, though comment-style type hints provide no risk there. And I would assume that at this point, any surviving py2 deployments are essentially forced to have pinned dependencies for everything anyway, so even lower chance of breaking something.

Maybe if there is ever a move to clean this repo and migrate to py3+ at some point, that would be the time to add hints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants