Fork https://github.com/google/pytype and clone your fork to your machine.
Follow the instructions in CONTRIBUTING.md for building and testing pytype.
Make your change! Make sure the tests pass, and linting and type-checking are clean.
Push your change to your fork and open a pull request (PR) against the original repo. If it’s your first time contributing to a Google open source project, please sign the Contributor License Agreement when prompted. Depending on what files your PR touches, it will be either merged directly or closed after being copied into the Google-internal codebase and re-exported to GitHub. You will be credited as the author either way.
Externally, pytype uses the GitHub issue tracker for issue management. You can filter by the good first issue and help wanted labels to find contributor-friendly issues. Please comment on an issue before starting any work, to avoid duplication of effort. When opening a PR to close an issue, include the following in the description to close the issue when the PR is merged:
XXX with the issue ID.) If a PR is relevant to an issue but doesn’t
fix it, you can link the two by mentioning the ID without the closing keyword.
Run the single-file analysis tool as
some_file.py for type errors, or
pytype-single some_file.py -o -
to infer a pyi (dumped to stdout via
-). The default target Python
version is the version that pytype is running under; pass in
to select a different version.
Note that the single-file tool does not handle dependency resolution, so you’ll have to supply .pyi files for all non-stdlib imports.
If you’re using the GitHub-installed tools, you can run the whole-project
pytype, over the file to generate a
.pytype directory that
includes the necessary .pyi files. Then add
--module-name <module> --imports_info .pytype/imports/<module>.imports
pytype-single invocation, replacing
<module> with the fully
qualified module name.
pytype can be run under pdb, the Python debugger. Add:
import pdb; pdb.set_trace()
at the point in the code at which you want to enter debugging.
For profiling a single file, pass in
--profile <path> to turn on profiling and
write the generated profile to
<path>. The profile can then be analyzed using
Note that numbers are not directly comparable between runs; differences of 100% for different machines on otherwise identical code have happened. The relative rank of functions in the profile is stable between runs.