Summary
Python 3.8 is dead, long live 3.13. Well, 3.12 if you play safe.
And unless 3.13 is delayed because of GC perf regressions.
But you can play with the new Python in Excel that is now generally available... maybe?
On a more technical note, PEP 741 (C API to configure Python initialization) has been approved. If you have no idea what this is about, don't worry, you are not alone.
Python 3.13 delayed?
It is expected that Python 3.13 will be released tomorrow, but it could be postponed for a week.
One of the main features of this version is a new incremental garbage collector, with smaller pauses. However, some popular projects, such as the documentation generator Sphinx, discovered significant performance regressions.
That's why there is such an emphasis on testing software during the RC.
Thomas Wouters, the core dev assuming the release manager position right now, called for reverting the change, something rarely done at such a late stage. The public discussions show no clear decision yet but the reversion patch has been approved, although not merged.
So we may be left hanging for another week before we start getting submerged by blog articles copy/pasting the released notes.
As with last year, I will specifically not do that and instead will write a "Python 3.13: what didn't make the headlines" instead once the dust has settled down.
And remember that we generally recommend to deploy Python one version below latest in prod, so really October is the occasion to upgrade to 3.12, not 3.13.
Great occasion to play with 3.13 though, especially the new GIL-less build.
Python 3.8 is dead
One benefit of aligning all the python release versions on the same one-year period is that when a new one come out, the oldest one can be deprecated at the same time.
Therefore tomorrow is also the time for Python 3.8 to leave security maintenance status and reach end-of-life: it won't receive any more patches.
Now, of course, it doesn't mean it will self-destruct, your server with 3.8 will still run for many years to come. Hell, we saw Python 2 still being used by 6% of people!
So if you are dependent on it, don't panic, the world is not ending. But you will see more and more new versions of libs dropping support for it. Then Linux distros and Docker images won't make them available for installation. And of course, no more security fixes.
Upgrading to 3.9 is the easiest path, and will be the less likely to break things. Of course, given it's work, if you can jump to 3.12, more power to you. It has very sweet error message improvements.
EDIT: It’s been brought to my attention that 3.8 will actually be EOL the 31th, not the 1st, of October. So we got effectively one month.
Python in Excel is generally available
Microsoft recently revealed Python in Excel as an alternative to the formula language (but not to VBA yet). You don't have to install anything, because it doesn't run on your machine, but in the cloud, and essential data science tools are available by default through Anaconda. E.G, querying cells returns a pandas dataframe, the UI to edit the code is a notebook, seaborn makes the plots, etc.
But it wasn't available to the general public yet, as it was only in preview mode, and you had to opt-in to the Insider Program to get access.
It's been rolled out worldwide now for all Windows users, and I'm curious of what are going to be the consequences of unleashing that into the corporate world.
Can't tell if it's a good or a bad thing.
In fact, I can't tell you much at all about it, because after paying the $140 for the privilege of using Office for one year:
py()
is unsupported in any online version of Excel available to me.Microsoft Offic 365 admin refuses to let me download any software, claiming I don't have a license.
Contacting the support, they sent me on a MS chase on several different domains, some of them didn't recognize my credentials at all.
Then the support chat crashed mid-session.
So far, trying to test Python for Excel has been a waste of my time and my money. Microsoft is still making it very hard to say anything nice about them after all those years. And I'm trying, I'm trying hard.
PEP 741 approved
Victor Stinner, who is responsible for many heavy contributions to Python that nobody talks about (like making UTF8 the default everywhere), is once again working in the shadow with PEP 741 – Python Configuration C API.
You can configure the Python interpreter with a lot of command line flags (like -X dev
to activate debug mode, -O
to strip assert
in prod) and env vars (e.g: PYTHONSTARTUP and PYTHONPATH).
So far though, it was not possible to dynamically configure the interpreter from code. This feature is more important today with multiple interpreters getting more love or the new JIT.
This PEP finally exposes a lot of internals to the C-API, so that at least for now, compiled extensions can start new Python processes in the setup they desire.
It's not sexy work, and it's complicated work. In fact, it took 2 years and a failed PEP 587 to reach a solution that could be accepted.
I think we are very lucky that 30 years into this Python thing, there are still people that champions relentlessly such improvements. There is no glory, no fame, and certainly a lot of trouble, in doing so.
Thanks Victor, and maybe see you in PyCon Strasbourg if I can make it.
This change should land in Python 3.14, and interestingly, it features a private module named _testcapi dedicated to playing with new features from Python directly. So you can give it a try.
It may be worth mentioning the Anaconda/defaults licensing mess in one of the upcoming notes. The shakedown is a disgrace.