How Python's RFC Process Paved the Way for uv, Ruff, and Ty

Astral, an independent startup, has taken the Python world by storm over the last few years with three fast, robust Python developer tools:

• ruff (linter and formatter)
• uv (packaging and project management)
• ty (static type checker, still under development)

These tools came from the mind of Charlie Marsh, who is neither a Python core developer nor directed by the Python Steering Council. While being independently developed, these tools work seamlessly within the established Python ecosystem. This success is in part due to Astral’s attention to the guidelines extablished by the Python Enhancement Proposal (PEP) process over the last twenty-five years

PEPs are the primary mechanism for proposing new language features, collecting community input, and documenting design decisions. The process is remarkably democratic: anyone can propose a PEP and acceptance requires community consensus and careful consideration of trade-offs.

The process works like this: someone writes a detailed technical specification, the community debates it (sometimes for years), and if consensus emerges, the Python Steering Council accepts it. Charlie and Astral’s developers have been guided by these standards and built tools that work within the existing ecosystem.

The Packaging Revolution: PEP 517, 518, and 621

For over a decade, Python packaging was effectively monopolized by setuptools. If you wanted to build a Python package, you wrote a setup.py file and hoped for the best. This created a chicken-and-egg problem: new packaging tools couldn’t emerge because everything assumed setuptools, and setuptools couldn’t improve because it had to maintain backward compatibility with every project ever written.

Three PEPs changed everything:

PEP 518 (2016) introduced pyproject.toml files. Instead of executable Python code in setup.py, projects could now declare their build requirements declaratively. Crucially, this broke the circular dependency problem so tools like pip could read the pyproject.toml to know which build system to install before running any build commands.

PEP 517 (2017) defined a standard interface for build backends. Any tool could now serve as a build system by implementing a few well-defined hooks. Build systems became interchangeable components rather than monolithic requirements. Developers can now choose the best tool for their job, and uv is among those options.

PEP 621 (2020) standardized project metadata in pyproject.toml, including uv’s metadata. No more fragmentation between setup.py, setup.cfg, and tool-specific formats. One file, one standard, readable by all tools.

Because of these PEPs, the community developed a breadth of new packaging and project management tools that could compete on performance and user experience without breaking compatibility.

Of course, I have to also mention PEP 723 (2023) which allowed Python files to declare their own dependencies inline using commented TOML syntax. This eliminated the need for separate requirements files for simple scripts and enabled truly self-contained Python programs. uv’s implementation of this has made Python more accessible to end users than ever.

The Typing Revolution: PEP 484 and the Static Analysis Foundation

In 2014, PEP 484 introduced type hints to Python, fundamentally changing how static analysis tools could understand Python code.

Prior to type hints, Python’s dynamic nature made comprehensive static analysis extremely difficult. Tools like pylint could catch basic errors, but complex analysis was nearly impossible without runtime information. PEP 484 changed this by providing a standardized way to annotate Python code with type information.

The typing system continued evolving through subsequent PEPs:

• PEP 526 (2016) added variable annotations
• PEP 544 (2017) introduced Protocol for structural subtyping
• PEP 585 (2020) enabled generic types from the standard library
• PEP 604 (2020) allowed union operators (|) for type unions

These foundations enabled tools like mypy and pyright to provide sophisticated static analysis. More importantly for Astral, it created the groundwork for parts of ruff’s linting capabilities and ty’s upcoming type checking features.

Code Quality Standards: PEP 8 and Beyond

Python’s commitment to standardization extends to code style through PEP 8, the official style guide. Published in 2001, PEP 8 established conventions for naming, indentation, line length, and import organization that became the foundation for every Python code formatter and linter.

But PEP 8 was just the beginning. The Python community continued developing standards for code quality including PEP 257 which, in 2001, defined docstring conventions.

These standards provided the blueprint that tools like ruff could implement. Rather than inventing arbitrary style rules, ruff enforces community-agreed standards that have been refined through years of discussion and real-world use.

The Standards Enable Innovation

By defining what tools should do without dictating how they should do it, PEPs create space for innovation while ensuring compatibility.

Consider how this played out with Astral’s tools:

uv didn’t need to reinvent packaging: it implemented the existing PEP 517/518/621 standards but did so with exceptional performance.

ruff didn’t need to debate what constitutes good Python code: PEP 8 and related standards already defined that. It could focus entirely on fast, accurate implementation of established rules.

ty isn’t inventing a type system: PEP 484 and its successors already did that. It can concentrate on providing faster, more accurate type checking within the existing framework.

Astral is building tools that respect and implement established standards while pushing the boundaries of performance and user experience.

Looking Forward

The relationship between standards and innovation in Python continues to evolve. Recent PEPs like PEP 735 (dependency groups) and PEP 751 (lock file format) are establishing new standards that future tools can build upon.

Astral’s tools demonstrate that Python’s democratic, standards-based approach to development creates an environment where innovation thrives. By establishing clear interfaces and leaving implementation details to tool authors, the PEP process has enabled a new generation of high-performance Python tooling that maintains compatibility with the broader ecosystem.