stub42/pytz

Mypy compliance / type checking

tgross35 opened this issue · 2 comments

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

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.

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.