TL;DR
- New typing features in Python 3.13 make large codebases easier to validate, maintain, and support with AI tooling.
- CPython’s new JIT is still early, but it shows real progress toward improving Python’s runtime speed.
- Python’s free-threaded build could unlock better multi-core performance, but library compatibility issues remain.
- Together, these changes show Python becoming more capable for performance-sensitive and AI-heavy applications.
It’s hard to believe, but Python, one of the most popular programming languages in the world, is now 35 years old. Yes, Python is a millennial.
Over its lifetime, Python has grown from an often-overlooked language to the default implementation language in a large number of domains and has become the darling of the data science world.
So how did we get here, and what’s next for Python?
How Python Became the Primary Language of Data Science
The machine learning revolution of the 2010s was one of the earliest catalysts of Python’s rise.
Python’s simple syntax and lack of boilerplate allowed data scientists to quickly analyze data without needing a deep understanding of programming concepts. According to JetBrains, more than half of the surveyed Python developers are involved in data exploration and processing.
A robust ecosystem sprang up around this use case, and libraries like NumPy, pandas, and scikit-learn further cemented Python’s status as the de facto programming language for data-heavy work.
The Impact of LLMs
The popularity of LLM-based AI applications further cements this trend.
The Q3 2025 edition of Dev Barometer found that 44.1% of surveyed developers plan to develop their AI and ML skills over the next 3 months. Two-thirds of BairesDev engineers think AI will redefine the developer role and speed up delivery.
Most of the popular LLMs are built on a Python implementation of the transformer architecture, courtesy of PyTorch. Despite the many drivers of Python’s popularity, Python still has many quirks that hamper its power and flexibility in key programming applications.
Fortunately, the Python community is one of the most vibrant out there, and it’s helping fuel further development.
What This Means for Talent and Companies
Python was the second most popular language on GitHub in 2025, posting a 48.78% year-over-year increase in contributions.
Popularity translates directly into talent demand. The BLS projects 15% growth for software developers through 2031, with Python-specific roles growing even faster. But the market has shifted from growth-at-all-costs hiring to precision hiring: teams are smaller, expectations are higher, and companies want developers who can contribute immediately. For many teams, generalist Python developers aren’t enough anymore.
Engineers who combine Python proficiency with machine learning, fintech expertise, or production AI command 20–40% premiums over baseline rates, and demand for that specialized talent hasn’t kept pace with supply. This means Python developers are under pressure to upskill and specialize.
This focus on AI and ML also puts pressure on the language itself, forcing it to evolve.
We will look at three recent developments and the latest Python trends, and discuss how they might affect the future of Python. Specifically, we will discuss the GIL, the JIT compiler, and type annotation improvements.
Global Interpreter Lock (GIL)
The Global Interpreter Lock has been one of the thorniest and most controversial features of the Python programming language for many years.
So what exactly is Python’s Global Interpreter Lock?
The GIL is essentially an interpreter-level lock that prevents code execution in more than one thread at a time. This was implemented as a simple and pragmatic solution to thread safety, where multiple threads interacting with the same set of variables could cause potential race conditions that lead to unpredictable code execution.
For example, suppose we were running a trading simulation where we cut off the algorithm when the losses get above a certain percentage of invested capital.
If the algorithm is tracking many trades in parallel threads, the sequence in which the trade is logged can mean the difference between breaching the cutoff threshold and recovering from a spate of early losses.
If there is no lock enforcing thread safety, the same code operating in the same environment can theoretically return completely different results based purely on which of the threads gets to write their trades first.
The Implications for Parallel Processing
Of course, in Python, the consequences extend far beyond simulation results. Thread safety can fundamentally destabilize the interpreter runtime itself by, for example, causing important variables to get unexpectedly deleted.
To solve this problem, the GIL essentially locks down the interpreter so that only one thread can execute at any given time.
This way, there is no risk of any two threads racing to access a single variable. While this is a simple and pragmatic solution, it severely constrains certain types of multithreaded applications. Because only one thread can execute at one time, CPU-bound workloads—the kind that require parallel computing and processing—cannot be sped up by multithreading.
If a programmer wanted to take advantage of parallel processing, they had to use multiprocessing, where a different instance of the interpreter is spun up with its own GIL. This workaround is still very limiting, however, because multiprocessing does not allow memory to be shared across parallel processes, resulting in significantly higher memory overhead.
To get around this problem, many attempts have been made to move Python to a per-object locking, where the lock is placed on specific memory references, instead of the thread execution itself.
In fact, there’s already a free-threaded build of Python that is available for installation and is supported by the Python Software Foundation, with a goal of making it the default build in a future release. This free-threaded build allows multiple threads to run on different cores while sharing memory. However, because the locking infrastructure is dramatically more complex, this overhead impacts performance when multithreading is not required. Additionally, because many libraries and extensions were developed with the GIL in mind, using the free-threaded version can introduce compatibility issues.
Despite these issues, however, there is significant energy behind replacing the GIL as AI becomes an increasingly significant use case for the Python programming language, where memory sharing across threads is particularly beneficial.
Python’s JIT Compilation
Just-in-Time (JIT) compilation has followed a similar trajectory to the GIL debate. Unlike compiled languages like C or Rust, Python is an interpreted language.
Instead of translating the code into machine code at compilation, the Python interpreter converts the Python script into bytecode that is read by an interpreter. The interpreter essentially acts as a virtual machine that converts the bytecode into actual machine instructions.
While this interpretation allows for amazing flexibility and dynamism within the language itself, the overhead of interpretation often makes Python much slower than other languages. Indeed, while Python has many strengths that led to its widespread use today, “speed” is rarely associated with the language.
JIT is a concept that introduces compiler-level optimizations for interpreted languages. When the runtime notices a piece of code being run over and over again, it compiles the code into machine code and replaces the bytecode instruction set with the much more optimized machine code.
Additionally, the runtime observes the environment around the compiled code for changes that would invalidate the compilation and return to bytecode execution in response.
In certain contexts where JIT optimizations are particularly useful, such as repeated numerical calculations, JIT-optimized Python runtimes such as PyPy have been shown to deliver up to 20x performance improvements on certain workloads, though CPython’s own experimental JIT currently yields more modest gains of 20–30% on CPU-bound tasks.
However, JIT has been difficult to implement due to various design features of the Python programming language. Precisely because it is so flexible and dynamic, Python’s execution environment can often be too unpredictable for many of the existing JIT techniques to work properly. Additionally, in order to support the large ecosystem of C extensions, Python has committed to an interoperability interface that makes it difficult to redesign the language to the extent needed for JIT. The very reason that Python is popular—the vast and powerful extension ecosystem—also works to constrain the kind of change that would enable JIT.
This is starting to change with Python 3.13 and 3.14.
Recent innovations in JIT techniques have led to promising new approaches that work within the constraints of the language, and an early, optional implementation of JIT is being rolled out in 3.13 and 3.14 with the goal of collecting feedback from developers who opt to turn it on. Once the developers have a better sense of JIT performance, a production version of JIT is expected to be rolled out in future versions, eventually becoming the default.
While an extremely complex problem, JIT implementations are seeing more interest than ever as Python becomes the de facto language of artificial intelligence. As Python codebases grow in size and complexity, the benefit one can gain from a well-implemented JIT increases dramatically.
If the maintainers of Python can build a compiler that can substantially improve the speed and performance of Python, they would help Python further entrench itself as the dominant language of the AI era.
What Type Annotations Mean for AI Work
Type Annotations were initially intended to be optional documentation hints for developers and code editors, but are now getting more attention in recent versions for two AI-related reasons.
Supporting Agentic AI Tools
First, modern agentic workflows are increasingly sophisticated, often requiring several layers of LLM calls and programmatic processing before returning a result.
Consequently, LLMs are often generating inputs to downstream processes, either in the form of tool calls, or in the form of structured outputs passed down into the next stage in the workflow. These generated inputs need to be validated against schemas before being handed off, and the typing system plays a crucial role in making sure the outputs conform to the schema.
AI Coding Agents
Second, AI coding agents are becoming increasingly mainstream, and they function best when the code is well-annotated and easily comprehensible.
A robust typing system goes a long way in making the code comprehensible to AI agents, since their code understanding still mostly relies on text comprehension.
What Changed in 3.13 and 3.14?
To support these use cases, several typing improvements have been made to the latest iterations of Python.
| Python version | Typing change | What changed | Why it matters |
| 3.13 | ReadOnly for TypedDict | Developers can mark specific TypedDict fields as read-only for type checkers. | Useful for agent state and structured outputs, where some fields should not be reassigned after initialization. |
| 3.13 | TypeIs | Adds a new way to narrow types in conditional branches, alongside TypeGuard. | Helps orchestration code distinguish between different response shapes, such as text outputs versus tool calls. |
| 3.13 | Type parameter defaults | Generic type parameters can now have default values. | Makes typed APIs and reusable libraries less verbose, especially in larger codebases. |
| 3.14 | Deferred evaluation of annotations | Annotations are now evaluated lazily instead of eagerly. | Reduces annotation overhead and makes typing-heavy code easier for frameworks and tools to work with at runtime. |
| 3.14 | annotationlib | Python added a standard library module for inspecting annotations. | Gives runtime tooling a cleaner way to read annotations, which matters for frameworks, validators, and AI-adjacent tooling. |
Starting in Python 3.13, developers can now mark TypedDict fields as read-only, which greatly benefits both of the AI use cases. In the agent orchestration use case, a popular pattern for agent orchestration involves defining a series of steps that each mutate an agent state, defined as a TypedDict.
The ability to mark a TypedDict field as a read-only adds an extra layer of safety against accidental state mutations by allowing static code analysis tools to catch when a read-only type is being reassigned after the state is instantiated. In the coding agent use case, marking a TypedDict field as read-only signals to the coding agent that it should not modify that field, reducing the chance of the agent introducing bugs by changing an important variable.
Another typing improvement introduced in Python 3.13 is TypeIs, which runs alongside the old TypeGuard annotation to provide more precise type narrowing for both if and else branches. The TypeIs annotation allows for better type analysis, which helps reduce bugs and improve code reliability.
TypeIs is particularly useful for agent orchestration code, where the system often has to differentiate between the various return types from the API, e.g., text response vs tool call response, etc. Better type analysis also makes AI coding agents more effective, since these agents often use type annotations to better understand code.
Taken together, Python is moving toward a more robust typing system that is meeting the moment as AI becomes an increasingly important use case for Python. Given the momentum behind these improvements, it is reasonable to expect more improvements to the typing system in future releases.
Now It’s AI’s Turn to Shape Python
We examined three specific areas where Python is seeing particularly dramatic improvements and explained how they could impact engineering teams.
- The Global Interpreter Lock, a feature of the programming language since the beginning, is being considered for removal in a future release.
- JIT compilation, which long eluded Python outside of niche implementations, might finally become a reality, allowing Python to compete on performance as well as flexibility.
- Typing improvements are putting Python on track to a robust type annotation system, making the language more tractable to static code analysis tools.
Python used to be one programming language among many strong contenders, but it is increasingly becoming the language of choice for a large number of use cases, and it dominates AI and data science. This is unlikely to change anytime soon.
As its popularity increases, Python continues to evolve and improve to meet the needs of new developers and AI-driven workflows. In essence, Python helped shape the AI systems we use today, and LLM workflows are now returning the favor by shaping the evolution of Python.
