It took the Python community a long time to move from Python 2 to Python 3. Now as we approach the possible end of Python 3 version history, we are approaching a potential Python 4.
What to expect in Python 4
Other than Python version 4 being mentioned in the PEP documentation, there is currently no formal writeup of the Python 4 feature-set.
Therefore we have to either believe that it will be the next version after 3.9, and will simply become 3.10. Otherwise it will fall back to version 4.
The industry argument around this continuing to 3.10 is based on the point that a major version bump from 3.* to 4.* should only be for breaking backward compatibility. Such as directed by semver (the Semantic Versioning standard).
Therefore, we can mention the primary features we would like to see in the next iteration. If it is to break version compatibility, then we will push some requests into the Version 4 Core branch.
What we want to see in Python 4
As a software engineer by trade, when working between languages, it becomes quite evident which features are superior in certain languages compared to other languages.
For concurrent programming paradigms, Golang has goroutines, Kotlin has coroutines, Java has the introduction of streams, which is taken one step further with ReactiveX and rxJava in particular. Even NodeJS is non-blocking by default, yet Python still lives in the dark ages with it’s single-threaded approach to software engineering.
Yes, there are ways to achieve concurrency, such as making use of the Multiprocessing libraries, or Asyncio. But all these approaches seem a bit haphazard and more challenging than they should be.
A core functionality and pythonic way of doing concurrent programming would be right near the top of the Python 4 wish-list.
Another feature to find it’s way as a primary contender, would be that of a way to statically compile code to a single binary. A cross platform way to do this would be first prize, but either way would be nice.
There are ways to achieve a similar thing, such as using Nuitka to automatically transpile Python project to C and then compile that seamlessly to a native binary. This actually works pretty well, and you can read more about it here.
It would be great if there were a built-in way to achieve this from the language itself.
What we still have in version 3
Main features in Python 3.7
Python 3.7 comes with many enhancements, such as the asyncio mobile having received new features and significant usability and performance improvements.
Improvements to the data model, in particular the dict type.
Enhancements and some postponements to the Evaluation of Annotations within the language.
A new forced UTF-8 runtime mode, where CPython ignores the locale settings and uses UTF-8 by default.
The time module received the ability to work with nanoseconds.
Additionally to all of this, there were also quite a few new modules for working with data collections, import libraries and overall improvements in many of the standard modules.
To see all the changes, view the list here.
Main features in Python 3.8
The Walrus operator :=
This can be used to assign a variable while using it, for example:
# Example 1
print(walrus := True) # True
# Example 2
if (n := len(a)) > 10:
print(f"List is too long ({n} elements, expected <= 10)")
# Example 3
while (block := f.read(256)) != '':
process(block)
Positional-only parameters
There is a new function parameter syntax / to indicate that some function parameters must be specified positionally and cannot be used as keyword arguments. This is the same notation shown by help() for C functions annotated with Larry Hastings’ Argument Clinic tool.
In the following example, parameters a and b are positional-only, while c or d can be positional or keyword, and e or f are required to be keywords:
def f(a, b, /, c, d, *, e, f):
print(a, b, c, d, e, f)
There are various other features, view them all here.
Main features in Python 3.9
Python 3.9 seems to be getting ready for a Python 4 on the horizon, with the removal of DeprecationWarning sections in the code that was used around Python 2.7 to Python 3.* migrations.
We are starting to see the removal of older versions compatibility.
Along with this, there are going to be new operators on the Dictionary type, such as merge and update. As well as some removeprefix and removesuffix methods on the string type.
There is also a new parser and various other language changes. For a full breakdown, see this Whats New page.
What’s your take?
Please leave your comments below for which features you would like Python 4 to prioritise and work towards building.