or should that be Pi-thon 3.14 is out. Even if the digits of Pi aren't burned into your ROM, it's still a big event for Python.

I have already covered the fact that the latest Python is a major upgrade for the GIL or rather not-the-GIL. The Global Interpreter Lock has long made it safe to run non-multitasking C extensions along with Python. Now you have the option of turning the GIL off and running threads that could be truly concurrent. This means that "serious" Python programs have the opportunity to be faster by taking advantage of multicore systems. Of course, most Python users aren't going to be writing such programs and my guess is most will opt not to complicate matters and will leave the GIL running for now.  In fact, I'm not sure that the majority of Python programmers have much idea what the GIL is or why turning it off might be helpful. I also think that the hoops that you have to jump through, easy though they might be, will also mean that the majority of Python programmers will not even try the GIL-less version.

Don't get me wrong, making Python fully multi-tasking is no small thing, but it is a bit niche. I expect Python library creators to take full advantage of it, but notice that many, NumPy for one, already have found ways of speeding things up by ignoring the GIL  - so don't expect everything to go faster.

So what's new for the rest of us?

Well the release notes tell it all, but it is long and many improvements are small. The intro mentions three things as being the "biggest" changes - template string literals, deferred evaluation of annotations and subinterpreters. In my opinion the biggest of the three is the support for subinterpreters. This is potentially more important that the removal of the GIL.

CPython has long offered the idea of running multiple copies of the Python interpreter in the same process, but now it is fully supported in the language and anyone can do it. The idea is very simple, but at first look very nuts. Just allow independent copies of the Python interpreter to run in the same process or even in different processes. This means that even with the GIL in place a Python program can run as separate "tasks" on different cores - i.e. true multitasking with virtually no effort. Of course, the crazy part is having multiple copies of the Python interpreter running at the same time. But is it really so crazy? Memory is cheap and the interpreter isn't that big. Why not make life easy by running a simple, but slightly more expensive, system? The simplicity comes from the fact that the interpreters don't share memory and this means that there are no accidentally shared resources as there are with threads. It does make inter-process communication slightly more difficult, but there are those who say it should be to avoid race conditions and so on. It's not perfect - we need better communication methods than just memoryview and support from other modules could be better - but it's a start.

Of the other two important updates, only string templates are likley to be widely appreciated. The idea is fairly simple - allow variables in string literals:

variety="Stilton"
template = t"Try some {variety} of cheese!"

The variable in the curly bracket is evaluated to give the final string. The sneaky thing is that a template is an object and you can use it to investigate the static and dynamic parts of the string literal. This sounds as if it wouldn't be that useful, but the documentation gives examples using it to sanitize HTML or SQL. 

As to the new deferred evaluation of annotations, thus is going to be important-ish to the few programmers who make extensive use of annotations - a minority I think.

Apart from these improvments we can look forward to better error messages complete with helpful suggestsions as to what you might have meant. If you type "whille" then the error message will smugly ask you "did you mean while". Yes of course I did, and why didn't you just autocorect it and get on with running a syntactically correct program!!! Unreasonable, yes? 

And if you are worried about pauses caused by the garbage collector then you will be pleased ot learn that it is now an incremental collector that reduces pause times by an order of magnitude. 

What I find comforting about 3.14, apart from the warm glow of the first three digits of Pi, is that there are no major upheavals. I like my Python as it is and don't want a revolution. Keep it up with small incremental changes and Python will continue to be my favorite language.  

• Mike James is the author of the Programmer's Python: Something Completely Different series of books which set out to show how Python diverges from other programming languages and how its special features deserve our attention. The third volume, Programmer’s Python: Async  on asynchronous and concurrent Python explores the problems posed by the GIL in detail. He solves many of Python's speed-related problems in Extending and Embedding Python Using C.

More Information

What’s new in Python 3.14

PEP 779: Criteria for supported status for free-threaded Python

Related Articles

Python Parallel? Not Quite Python 14

Python 3.13 Is Here

Goodbye GIL - But Will It Make Python Faster?

Python 3.11 Goes Faster

Python 3.11 Released

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:B0B5522QS3>

<ASIN:B09ZGBHMG9>

<ASIN:B0BHDWZY62>

<ASIN:B0CK3X93KF>