Welcome! Mypy is a community project that aims to work for a wide range of Python users and Python codebases. If you‘re trying mypy on your Python code, your experience and what you can contribute are important to the project’s success.
Everyone participating in the Mypy community, and in particular in our issue tracker, pull requests, and chat, is expected to treat other people with respect and more generally to follow the guidelines articulated in the Python Community Code of Conduct.
Within Github, navigate to https://github.com/python/mypy and fork the repository.
git clone git@github.com:<your_username>/mypy.git cd mypy
# On Windows, the commands may be slightly different. For more details, see # https://docs.python.org/3/library/venv.html#creating-virtual-environments python3 -m venv venv source venv/bin/activate
python3 -m pip install -r test-requirements.txt python3 -m pip install -e . hash -r # This resets shell PATH cache, not necessary on Windows
Note You'll need Python 3.8 or higher to install all requirements listed in test-requirements.txt
Running the full test suite can take a while, and usually isn‘t necessary when preparing a PR. Once you file a PR, the full test suite will run on GitHub. You’ll then be able to see any test failures, and make any necessary changes to your PR.
However, if you wish to do so, you can run the full test suite like this:
python3 runtests.py
You can also use tox
to run tests (tox
handles setting up the test environment for you):
tox run -e py # Or some specific python version: tox run -e py39 # Or some specific command: tox run -e lint
Some useful commands for running specific tests include:
# Use mypy to check mypy's own code python3 runtests.py self # or equivalently: python3 -m mypy --config-file mypy_self_check.ini -p mypy # Run a single test from the test suite pytest -n0 -k 'test_name' # Run all test cases in the "test-data/unit/check-dataclasses.test" file pytest mypy/test/testcheck.py::TypeCheckSuite::check-dataclasses.test # Run the formatters and linters python runtests.py lint
For an in-depth guide on running and writing tests, see the README in the test-data directory.
If you're looking for things to help with, browse our issue tracker!
In particular, look for:
You do not need to ask for permission to work on any of these issues. Just fix the issue yourself, try to add a unit test and open a pull request.
To get help fixing a specific issue, it‘s often best to comment on the issue itself. You’re much more likely to get help if you provide details about what you‘ve tried and where you’ve looked (maintainers tend to help those who help themselves). gitter can also be a good place to ask for help.
Interactive debuggers like pdb
and ipdb
are really useful for getting started with the mypy codebase. This is a useful tutorial.
It's also extremely easy to get started contributing to our sister project typeshed that provides type stubs for libraries. This is a great way to become familiar with type syntax.
Even more excellent than a good bug report is a fix for a bug, or the implementation of a much-needed new feature. We'd love to have your contributions.
We use the usual GitHub pull-request flow, which may be familiar to you if you've contributed to other projects on GitHub. For the mechanics, see our git and GitHub workflow help page, or GitHub's own documentation.
Anyone interested in Mypy may review your code. One of the Mypy core developers will merge your pull request when they think it's ready.
If your change will be a significant amount of work to write, we highly recommend starting by opening an issue laying out what you want to do. That lets a conversation happen early in case other contributors disagree with what you'd like to do or have ideas that will help you do it.
The best pull requests are focused, clearly describe what they‘re for and why they’re correct, and contain tests for whatever changes they make to the code's behavior. As a bonus these are easiest for someone to review, which helps your pull request get merged quickly! Standard advice about good pull requests for open-source projects applies; we have our own writeup of this advice.
Also, do not squash your commits after you have submitted a pull request, as this erases context during review. We will squash commits when the pull request is merged.
You may also find other pages in the Mypy developer guide helpful in developing your change.
Core developers should follow these rules when processing pull requests:
git log
output):git log
output.