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

Pyright vs mypy #106

Closed
robsys opened this issue Jan 27, 2024 · 5 comments · Fixed by #125
Closed

Pyright vs mypy #106

robsys opened this issue Jan 27, 2024 · 5 comments · Fixed by #125
Assignees
Labels
enhancement New feature or request

Comments

@robsys
Copy link

robsys commented Jan 27, 2024

Just wanted to open up a discussion. Have you thought about giving pyright a try instead of using mypy?
I'm curious if you find one more favorable or effective than the other, let's discuss! What are your thoughts?

@robsys robsys added the enhancement New feature or request label Jan 27, 2024
@szvsw
Copy link
Contributor

szvsw commented Sep 24, 2024

For what it's worth the first thing I do after running ccp is replace all the mypy stuff with pyright. might be nice if that was one of the config options in the ccp scaffolding.

@fpgmaas
Copy link
Owner

fpgmaas commented Sep 25, 2024

Thanks for raising @robsys, and thanks for letting me know @szvsw. I haven't used pyright myself. It looks like mypy is used a lot more than pyright:

  • mypy: 36.9m downloads/month
  • pyright: 4.9m downloads/month

I try to strike the right balance between opinionated and flexible in this template, but in general try to keep options limited, because for each option, the amount of variations that needs to be tested effectively doubles.

However, I can see that this is something that users have different preferences over, so it probably would be good to support pyright as well. If someone is willing to add pyright as an option for the type checking I'd be open for that.

@szvsw
Copy link
Contributor

szvsw commented Sep 25, 2024

One thing to consider is that the (effectively) built in type checker within VSCode is PyRight (within Pylance):

https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance

https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright

It's not immediately clear what percent of VSCode users enable type checking, but it is Microsoft's out-of-the-box built-in first-class supported type checker for python, which is not nothing IMO.

But yes I take your point in re not wanting to create too many options and being opinionated.

If I have some time over the next month or so, I'll see if I can get familiar with how cookiecutter works so I can open a PR for pyright.

Sam

@szvsw szvsw mentioned this issue Sep 25, 2024
4 tasks
@szvsw
Copy link
Contributor

szvsw commented Sep 25, 2024

Okay, so it turns out I couldn't sleep and this is trivially easy to implement, so I opened a PR. I could use your input on how you want to set up the typechecker testing, but once that's in it should be good to go. I personally add pyright to my precommit hooks, but I think that can be left to the user.

Here's an example repo with an intentional type failure:

https://github.com/szvsw/test-pyright-ccp

@szvsw
Copy link
Contributor

szvsw commented Sep 26, 2024

Okay, #125 is ready for review.

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

Successfully merging a pull request may close this issue.

3 participants