A static type analyzer for Python code
Home
Developer guide
Workflow
• Development process
• Python version upgrades
• Supporting new features
Program analysis
• Bytecode
• Directives
• Main loop
• Stack frames
• Typegraph
Data representation
• Abstract values
• Attributes
• Overlays
• Special builtins
• Type annotations
• Type stubs
• TypeVars
Configuration
Style guide
Tools
Documentation debugging
View the Project on GitHub google/pytype
Hosted on GitHub Pages — Theme by orderedlist
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:
Resolves #XXX
(Replace 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
pytype-single some_file.py
to check 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 -V<major>.<minor>
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
analysis tool, 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
to your 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
the pstats
module.
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.
Pytype’s typegraph is being rewritten to improve performance and correctness. The new code lives in the pytype/rewrite/ directory. To run pytype’s tests with the new code:
Open pytype/tests/test_base.py
and change the value of the _USE_REWRITE
module constant from False
to True
.