Conference Presentation, Lecture
Neil Mitchell: Pyrefly: Type Checking 1.8 Million Lines of Python Per Second
- The Python type system is expected to grow increasingly complex annually as developers migrate untyped code to typed systems, with 2025 tentatively identified as a pivotal year for type checking adoption, contingent on community progress.
- The tool Pyrefly is currently in an alpha state but deemed sufficient for use, with plans to integrate into build systems including Dune and Bazel, while native support for Pydantic is confirmed and Django extension development is underway.
- The team aims to handle codebases of 20 million lines by processing invalidations at the file level, requiring check speeds of a few milliseconds per file to maintain IDE performance during keystrokes.
- To achieve high performance, the tool is implemented in Rust rather than Python, leveraging multi-threading capabilities introduced in Python 3.13 free-threaded mode, with future optimizations planned for thread pool parallelism which currently represents only 35% of the profiling load.
- Users can typically achieve a "pyre-fly clean" state in one day for most projects, though the tool intentionally rejects code that is definitively wrong to catch errors missed by other checkers, prioritizing strict error detection over maximum compatibility.
- The system relies on a six-step linear build process (code, AST, exports, binding, answers, interface) to manage concurrency and dependency invalidation, using a "less fixed point" algorithm to resolve circular import graphs and module exports without memory bloat.
- Type inference strategies prioritize common user expectations, such as generalizing list literals to "list of int" and inferring unions for common base classes, while utilizing a "var" primitive to handle recursion and deferring unification to avoid confusing "most general type" instantiations.
- Project management involves over 100 contributors active on the tool, with bug fixes handled internally or via pull requests, and a strategy to consolidate support for extensions directly into the core Pyrefly binary rather than evolving a separate API.
- A significant technical risk involves the "horrific" complexity of the least fixed point algorithm required for
import *cycles, while a strategic risk exists where losing type information would cause critical issues at Meta due to their reliance on types for scalable code changes. - Future efficiency improvements are anticipated through better memory management for interfaces versus answers and the eventual implementation of a thread pool, while the tool handles circular dependencies by invalidating entire cycles if interface dependencies change unexpectedly.