[feature] adding mypy for static typing

[sergey-koldyba]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @sergey-koldyba, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request integrates Mypy into the project's development workflow to enforce static type checking for Python code. It sets up the necessary configurations in pre-commit hooks, VSCode settings, and project dependencies, while also applying initial type hints to a sample file and updating documentation.

Highlights

• Static Type Checking Integration: I've introduced Mypy for static type checking of Python code. This includes adding a mypy pre-commit hook to ensure type correctness before commits.
• Development Environment Configuration: The development environment has been updated to support Mypy. This involves adding Mypy and its related type stubs as development dependencies in pyproject.toml, configuring Mypy's strictness rules, and recommending the Mypy VSCode extension with appropriate settings for seamless integration.
• Codebase Type Hinting: Initial type hints have been added to the src/hello.py file, specifically for function return types, demonstrating the application of static typing to existing code.
• Documentation Updates: The README.md has been updated to reflect the new type checking capabilities, providing instructions on how to run Mypy locally and clarifying its role in the development and CI workflows.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces mypy for static type checking, which is a great addition for improving code quality. The changes include adding mypy to pre-commit hooks, configuring it with strict settings in pyproject.toml, adding it as a dev dependency, integrating it with VS Code, and updating documentation and existing code with type hints. I've provided a few suggestions to improve the VS Code integration and clean up the configuration.

[dmitrii-palisaderesearch]

Does it make sense to switch IDE to mypy from pyright / pylance? I understand we can use pyright for CI purposes also.

https://www.reddit.com/r/Python/comments/1i8pm2f/any_reason_to_not_use_pyright/ left me with the impression we should stay with defaults (=pyright) while we can.

[sergey-koldyba]

Does it make sense to switch IDE to mypy from pyright / pylance? I understand we can use pyright for CI purposes also.

https://www.reddit.com/r/Python/comments/1i8pm2f/any_reason_to_not_use_pyright/ left me with the impression we should stay with defaults (=pyright) while we can.

Actually, I would say it's rather matter of taste than a strict rule. I personally don't like the idea of having node package for python type checking.
Seems like both may struggle in Cursor due to using pylance
Also this topic suggests usage of pyright fork named basedpyright. We can give it a shot, it has enough stars on github for my taste. WDYT?

[dmitrii-palisaderesearch]

Why is this so hard(

I learned much more than I wanted to know from skimming https://news.ycombinator.com/item?id=43918484 + https://docs.basedpyright.com/latest/.

Wdyt we trust Astral once more and go with https://docs.astral.sh/ty/ despite it being alpha? Worst case we break typing which is not worse than the status quo of not having typing.

UPD: regardless of what we decide I suggest first testing this change on some ongoing project before merging to template

[sergey-koldyba]

Why is this so hard(
It seems that I have done more harm than good with this task 🥲

However, ty looks promising. IDK why I haven't stumbled into that.
I'm not a huge fan of non-prod-ready tools(for reasons), but we're not prod-ready as well, so, why not?
Let me add everything to the PR so it's ready to merge and I'll try to find some project to be my guinea pig.

[sergey-koldyba]

So moved to ty. Also, Switched language server to ty as well and removed Black Formatter extension(as we use ruff)
Didn't alter rules defaults - they look fine to me.

[sergey-koldyba]

Added ty to mis-schm and big-boba

LGTM, can we merge? @dmitrii-palisaderesearch