Getting Started Developing

Just a couple of hints:

• You can parse a file and dump the parse tree by running the misc/dump-ast.py script. This can make it easier to get familiar with the internals.

• A debugger can be a very useful way of getting familiar with a codebase. Specifically, if you try running mypy and get an unexpected error message, try searching for the corresponding string within messages.py. The messages.py file contains the bulk of the error-formatting and logging code.

  Attach a breakpoint to the corresponding line and run your debugger. Once it pauses, examine the stack trace: that should help give you an idea of how your input file was handled by mypy. Alternatively, raise an exception there (this works without a debugger).

• Git blame can be a useful way of getting context into why a particular snippet of code exists. If you're not sure how to use git blame from the command line, you can use it from Github's web interface: navigate to a file and click the "blame" button in the upper-right.

• If you're repeatedly running mypy against several files and want to test or tweak something in the semantic analysis or type checking phase, consider disabling incremental mode via the --no-incremental flag. This will force mypy to re-check each file.

PyCharm

Our test suite runs by default in parallel mode (meaning we run all tests distributed over the number of processes available on your machine). We achieve this by adding -n auto to the pytest.ini files addopts. This may cause issues with the PyCharm debugger; you can add either set the PYTEST_ADDOPTS environment variable to contain value -n0 or add this argument to your pytest invocation. With this you'll be back in sequential execution land.