We’re excited to share a year-long research effort aimed at making Python’s type system more expressive and composable, something closer in spirit to the programmable types in TypeScript, but carefully crafted for Python’s runtime model. The result is PEP 827: Type Manipulation.
Python’s runtime is incredibly powerful: classes, methods, and even whole APIs can be generated on the fly from a few lines of code. Concepts like metaprogramming can transform class declarations, decorators can give functions and methods additional behaviors, and those are just a few examples.
But Python's static typing often can’t “follow along” without typechecker plugins or boilerplate code. PEP 827 proposes a set of standard, type-level building blocks for introspecting existing types and constructing new ones, designed to help both type checkers and runtime tooling.
FastAPI creator Sebastián Ramírez summed up the potential impact well on our post in the Python Discourse:
Link to headingQuick taste
One concrete example is the familiar TypeScript utility types, like Pick and Omit. Here's Pick implemented in TypeScript and Python side by side:
We can immediately see that the TypeScript dedicated typing syntax is short and to the point, albeit quite different from the rest of the language. Python, on the other hand, relies on the standard Python imperative syntax combined with type-level APIs.
Now let's look at how Omit can be implemented:
Interestingly enough, Python's version is more in line with the Pick implementation, the only difference is inverting the condition. TypeScript, on the other hand, composes quite differently, and requires a deeper rewrite.
This illustrates that the big idea isn't "make Python look like TypeScript." It’s to give Python typing a programmable core that matches Python’s semantics and stays introspectable at runtime, so frameworks like Pydantic can benefit too.
Link to headingWhat's next
PEPs are debated, revised, and sometimes rejected. We’re excited to be part of that process, and we invested in this research because we build across TypeScript and Python and want both ecosystems to thrive.
One might ask: in an age where agents are writing an increasing share of source code, should we even care about programming language syntax, tooling, or type system capabilities?
We argue the answer is, more than ever, "yes". We want type checkers to be more thorough and frameworks to be more expressive, so that we can safely ship more reviewable, succinct code. The less boilerplate we have to maintain, the better, and we don’t see that changing anytime soon.
So yes, agents will care. And so will we.