Credit: John Salvino
Python has many great features—convenience, a wide range of powerful libraries, a helpful community of users—but a few elements are still missing. Some features found in other languages would make certain jobs easier, but they aren't coming to Python anytime soon.
Here are four commonly requested language features that are currently not in the cards for Python. At least two of them will never happen, while the others are, at best, years down the line. We'll look at what's blocking these features, or what it would take to include them in a future version of Python.
Nope: A statically typed, compiled version of Python
Some developers dream of a Python that uses static typing to compile to native machine code. Flexible typing is the source of much of Python's slowness, after all, and static typing would put an end to that. Static typing also gives programmers strong guarantees of what to expect from their code. So, what's the issue?
While Python does have type hints, they are intended to make the language more amenable to static analysis at edit time, by way of linting tools. Only third-party projects (such as pydantic) use type hints at runtime. The Python runtime by itself does not use type hints.
One of the explicit goals in PEP 484, the Python Enhancement Proposal for type hinting, was for type hints to be forever optional. "Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention."
Developers who really want a statically-typed version of Python can turn to Cython or mypyc, but even those projects come with tradeoffs. In the case of Cython, the greatest performance boost comes from using pure C types and structures, and reducing the use of the Python runtime. Simply put, it's hard to make Python compile faster without sacrificing its dynamism. It's far easier to take the parts that don't need dynamism, separate them, and speed them up.
Nope: Multiline lambdas
Python's lambda expressions, or anonymous functions, are deliberately limited. They only allow a single expression (essentially, anything to the right of the = sign in an assignment operation) as the function body. Developers coming to Python from languages like JavaScript, where multiline anonymous functions are the norm, often ask for this feature in Python.
Python's creator, Guido van Rossum, long ago shot down the idea of a lambda being anything but syntactic sugar for a single expression. His position is best encapsulated in an email from 2006, where he discusses why multiline lambdas aren't and won't be a thing in Python:
- Multiline lambdas would add little or no actual power or expressivity to Python, and would come at the cost of making it a less readable language. (Readability is a prime concern for Python.)
- No usable syntax has been offered that would integrate elegantly with the rest of Python's whitespace-sensitive design.
- It takes little effort to convert a multiline lambda into a full-blown function, which van Rossum recommends as the use case for a "multiline lambda" scenario, anyway.
Needless to say, the future does not look bright for multiline lambdas in Python.
Unlikely: A Python without a GIL
The Global Interpreter Lock, or GIL, has long been a thorn in the side for Python lovers. GIL synchronizes activity within the Python runtime to serialise access to objects and manage global state. GIL's downside is that it makes the Python runtime single-threaded in practice. If you want true parallelism with threads, you need to launch discrete copies of the Python interpreter and run separate threads on each one. Python without a GIL could, in theory, allow far greater parallelism, and thus a boost in performance. So, why is it unlikely?
There have been various proposals to remove GIL from Python. Most would break backward compatibility, or would make Python slower for single-threaded operations, or would do both. One effort, the "GILectomy" project came with a serious performance penalty. Python 3.x reworked GIL to improve its baseline performance, but did not remove it in order preserve backward compatibility.
Because of these concerns, GIL may simply be a fact of life for Python users. But there are possibilities for improving its performance. One way to allow better parallelism in the Python runtime would be running multiple interpreters in a single process. Making that proposal a reality would require significant changes to Python's internals, including reworking parts of Python's C API. Many third-party modules depend on the C API, and would also need to be updated.
A newer proposal, PEP 684, expands on the idea of multiple interpreters to have each subinterpreter use its own GIL. In this case, the proposed change would also allow for strategically sharing objects that needed to be shared between the subinterpreters.
Maybe: A Python-native JIT compiler
One proven way to make Python faster while keeping the language's beloved flexibility is to use a just-in-time compiler, or JIT. JIT compilation involves analyzing code at runtime, rather than ahead of time, and compiling it selectively or entirely to machine code based on the behaviors it exhibits while it's running.
JITs already exist for Python. PyPy, the most commonly used and best-developed example, excels at making long-running, server-style applications deliver improved performance without modifying program source code. But would Python's reference version, CPython, benefit from having a JIT of some kind?
Recent initiatives to make Python faster, discussed at the 2021 Python Language Summit, generated a few proposals along those lines. Rather than implement a full-blown JIT in Python, the current proposals involve adding adaptive behaviors to the interpreter for faster execution in common specialised cases. There may be room for other kinds of JIT-type specialisation in the future, such as generating machine code for truly high-speed code paths. But the near-term plan is to make improvements that extend the existing interpreter rather than replacing it.
