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 static type checking #69

Closed
joshthoward opened this issue Jan 14, 2021 · 6 comments
Closed

Mypy static type checking #69

joshthoward opened this issue Jan 14, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@joshthoward
Copy link
Member

Posting this here to gauge interest...

Does the community think that mypy static type checking would be a benefit? For users, this would enable type hints in modern IDEs. For developers, this would enable yet another check to ensure correctness while building.

I'm happy to implement this BTW, just wanting to ensure that it would be well received prior to expending the effort.

Thoughts?

@nineinchnick
Copy link
Member

There should be no negative side effects and since SQL is strongly typed it makes sense to add type hints to a driver like this :-)

@joshthoward
Copy link
Member Author

Part of the challenge is the difference in type annotations for Python 2 and Python 3 (old Python 2 example is here). If we would like to enable static type checking, we should consider removing Python 2 support (see issue here).

@pgagnon
Copy link
Member

pgagnon commented Jan 16, 2021

Part of the challenge is the difference in type annotations for Python 2 and Python 3 (old Python 2 example is here). If we would like to enable static type checking, we should consider removing Python 2 support (see issue here).

If we must keep Python 2 support we could put a stub in typeshed instead, but I'd highly suggest removing it anyway as Python 2 is EOL and has been deprecated for over 10 years.

@pgagnon pgagnon added the enhancement New feature or request label Jan 16, 2021
@electrum
Copy link
Member

As someone who prefers statically typed languages and developing in powerful IDEs, I’m all for this. But as a casual Python user, I don’t know if there are any downsides.

From my quick research, it seems there is the PEP 484 standard for type hints, and then tools like Mypy or Pyright that utilize them. If that’s accurate, I’d like to understand why we’d pick one tool over another, or if that is more of a concern for users of the library.

I also found https://github.com/Instagram/MonkeyType which looks like it might help with adding the annotations.

@pgagnon
Copy link
Member

pgagnon commented Jan 17, 2021

As someone who prefers statically typed languages and developing in powerful IDEs, I’m all for this. But as a casual Python user, I don’t know if there are any downsides.

From a runtime perspective there is no downside as type hints do not alter runtime behavior at all so this is strictly a linting/CI/IDE concern.

From my quick research, it seems there is the PEP 484 standard for type hints, and then tools like Mypy or Pyright that utilize them. If that’s accurate, I’d like to understand why we’d pick one tool over another, or if that is more of a concern for users of the library.

The type hints would be the same no matter what type checking tool we would use, so choosing between mypy or another type checking implementation would only be a concern if we decide to implement type checking in CI for the project. My two cents though, I would recommend using mypy as it's the reference implementation and more widely used.

@hashhar
Copy link
Member

hashhar commented Dec 15, 2021

@joshthoward Does #91 cover all the things we wanted to do here? I'm closing this because I think it did. If there's something remaining feel free to re-open or create a new issue as you see fit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

5 participants