pyca / pynacl

Python binding to the Networking and Cryptography (NaCl) library
https://pynacl.readthedocs.io/
Apache License 2.0
1.06k stars 233 forks source link

Type annotations for `nacl.exceptions` #694

Closed DMRobertson closed 2 years ago

DMRobertson commented 2 years ago

Following on from #693, I've pulled out the changes in #692 which relate to nacl.exceptions (and applied a suggestion of @Dreamsorcerer in the process). I picked this module because it was a leaf: it doesn't import any other things from nacl.

The code changes are small; instead, I think we'll have more to say about the mypy config changes. I've turned on a bunch of extra checks for nacl.exceptions only. I'd hoped that I could enable strict mode on a module-by-module basis, but that doesn't seem to be possible. So instead, I went through the mypy documentation and turned on every check that sounded good for type safety.

(At work, I've found disallowing the propagation of Any, and disallow_untyped_defs the most useful: they help ensure that mypy is actually able to do type checking in the first place!)

If you're happy with this list of checks, my plan would be to take on other modules and add them one-by-one to the "strict" section in pyproject.toml. In the long run I'd like to have everything in pynacl under this list, at which point we can drop the per-module override and have a single set of package-wide configuration for mypy.

reaperhulk commented 2 years ago

I have no objections to being aggressive with our mypy flags here, but I agree that we only want these override sections to be a temporary thing.

Dreamsorcerer commented 2 years ago

The code changes are small; instead, I think we'll have more to say about the mypy config changes. I've turned on a bunch of extra checks for nacl.exceptions only. I'd hoped that I could enable strict mode on a module-by-module basis, but that doesn't seem to be possible. So instead, I went through the mypy documentation and turned on every check that sounded good for type safety.

--strict is basically just a stricter default set of configs. Using the config file is preferable as it gives more finegrained control, and the config you've created is actually a lot stricter than --strict.

This also has the advantage that anybody can just run mypy and it will typecheck everything with the same settings, rather than a user needing to know what arguments/files to pass to the command.