Why I’m Excited For Python 3.9
Only the nerdiest of nerds get excited for new, incremental Python releases, but here we are! I am absolutely ecstatic for Python version 3.9, and here is why:
PEP 585
“Wait, what?” I hear you asking. PEP 585 basically makes optional type checking a first class feature of Python. While this is not a major change (this type of optional type checking has been around for a while), it does begin to pave the way for something much more important. Just In Time compilers (JITs for short). These are significant because it begins to help pave the way for a Python that is no longer a scripting language for tying together a bunch of disparate libraries. Lots of which are written in C anyways! It begins to make it a language that could legitimately be used for more CPU intensive workloads without offloading all of that to another language like C.
We have seen the power of JITs in Python before. Numba is a project built on top of NumPy that compiles functions in Python. Numba does have its limitations though. Numba works best with numerical operations over NumPy arrays. This limitation makes the usability of Numba quite a bit worse, but still a very useful and amazing library.
[Not a plug, but I really am a fan of the work they have been doing over there]
If you listen to some of the talks given by team members, they will often say that one of the biggest reasons that it has the limitations it does is because of the dynamic typing inherent to Python. And this makes sense, compilation does rely, to some extent, on knowing the size of the data that you are working with.
So let’s address the elephant in the room, JavaScript and V8. V8 is a JIT that runs the JavaScript language. It is the basis for Node.js and Chrome. It is blindingly fast. There is no doubt about it. So how can JavaScript have a good JIT but Python can’t. JavaScript is dynamically typed as well! Well it really comes down to money and time. V8 is backed by Google, and has lots of resources dedicated to its maintenance. Python (while still a massive project) just doesn’t have the resources to do things like hyper complicated JITs.
However, if Python can solve some of the complexities by adding some simple language features, then suddenly the possibility of a JIT runtime for Python becomes more of a possibility.
Now, I recognize that this is quite the long shot. There are still lots of complicated technical issues that would need to be solved. Most of which are way outside of my wheelhouse.
But imagine the possibilities!
If there were a serious, performant, JIT runtime for Python, it would suddenly solve one of the major issues that have plagued Python for a long time.
Python.
Is.
SLOW!
And I’m not just talking a little slow, but really slow. There are worst offenders, but still. But if suddenly the performance of Python could rival that of other JIT languages, there might be something to talk about.
If one were able to be implemented, [more] CPU intensive applications could be written. More pure Python libraries could be written (cutting down on some of the dependency hell that can spring up at the moment). Existing applications could see a much needed boon to performance!
It would make the Python ecosystem much more flexible and robust. Offering both performant, statically typed code, and flexible, dynamically typed code. All living side by side.
Now, much of this is wishful thinking from someone who is definitely much more of a user of programming languages and frameworks than a maker of them. But I am still hopeful that this most recent revision to Python lays the groundwork for such a world. Or really just any step towards it.
