From PEP 690's rejection to PEP 810's unanimous acceptance — how Python finally got explicit lazy imports after three years of real-world production evidence and a fundamental design inversion
You run mytool --help and wait. Two seconds. Three. No network requests, no error, no disk thrashing. Just Python dutifully loading PyTorch, NumPy, pandas, and a dozen other heavy libraries it will never touch — all so it can print a usage message and exit. This isn’t a hypothetical scenario from a conference slide deck. This is what Instagram engineers were dealing with every day in production. It’s what Hudson River Trading’s researchers were enduring across hundreds of CLI tools in their monorepo. And it’s the reason Python now has a lazy keyword coming in version 3.15 — though getting there took three years, two PEPs, a Steering Council rejection, a Language Summit showdown, and production evidence from some of the largest Python codebases on the planet.
The Companies That Couldn’t Wait#
Long before the Python Steering Council had any consensus on how to solve the import problem, the companies running the biggest Python codebases had already solved it themselves. They had to. Waiting wasn’t an option.
Meta built Cinder, a performance-oriented fork of CPython that included lazy imports alongside a JIT compiler and a handful of other aggressive optimizations. Instagram’s backend ran on Cinder. The team documented their results: startup time improved by up to 70%, and memory usage dropped by up to 40% on real-world CLI tools. Germán Méndez Bravo, who implemented the lazy imports feature inside Instagram’s codebase, later described how the transition was surprisingly smooth for most internal code — the overwhelming majority of modules just worked when laziness was enabled globally.
Hudson River Trading (HRT), the quantitative trading firm, did something similar. Their Python ecosystem lives in a monorepo where internal modules are importable everywhere — convenient for collaboration, painful for performance. In the most tangled portions of their codebase, a single script’s imports alone could take over thirty seconds. A small volunteer team built a prototype during HRT’s 2023 internal hackathon (they call it “Surge”), forking CPython 3.10 and cherry-picking lazy import commits from Cinder. The prototype worked well enough to get greenlit for full-time investment. By Q2 2025, HRT had migrated the entire firm to lazy-by-default Python. Their August 2025 blog post is unusually candid: tools that previously cost users several minutes just to start up now launched in seconds.
The point here isn’t that these companies are clever. The point is that the need for lazy imports was real enough, and urgent enough, that sophisticated engineering organizations were willing to fork CPython and maintain their own interpreters to get it. That’s not something anyone does for a nice-to-have feature. That’s the kind of signal that a language’s governance body can’t easily ignore.
PEP 690: The First Attempt#
In April 2022, Germán Méndez Bravo and Carl Meyer — both at Meta — wrote PEP 690. Barry Warsaw, a longtime Python core developer then at LinkedIn, sponsored the proposal. The design was straightforward and practical: add a -L flag (and a corresponding importlib.set_lazy_imports() API) to make all imports lazy by default. Application developers could flip the switch once and get the gains across their entire codebase without annotating thousands of individual import lines.
The workaround PEP 690 was trying to replace looked like this:
... continue reading