• Python without the GIL, for good

• LPython: a new Python Compiler

• Pydantic 2 is getting usable

• PEP 387 defines “Soft Deprecation”, getopt and optparse soft deprecated

• Cython 3.0 released with better pure Python support

• PEP 722 – Dependency specification for single-file scripts

• Python VSCode support gets faster

• Paint in the terminal

We saw last month the Global Interpreter Lock was the center of attention once again. This month it carried on to the point than even Meta, Facebook’s parent company, pitched in:

If PEP 703 is accepted, Meta can commit to support in the form of three [engineer years on landing] nogil CPython

It is nice to have Python seeing more and more contributions from the big companies that used it for their success. It’s a huge contrast compared to the 2010 decade.

The discussion culminated with an internal debate with the core devs, which ended up with an official announcement that PEP 703, the proposal that relit the fire, was going to be accepted after some details being figured out.

This means in the coming years, Python will have its GIL removed.

Here is the plan:

• Short term, an unsupported experimental version of Python without the GIL is published in parallel to the regular one. Target is 3.13/3.14.

• Mid-term, the no-GIL version is marked as officially supported, but is still just an alternative to Python with GIL. A target date is announced to make it the default once. This will happen only after the community has shown enough support for it, and will take several years.

• Long-term, no-GIL becomes the default. Before this, the core devs can reverse the decision and abort the no-GIL project if it proves to have a bad ROI.

Note that if the program imports one single C-extension that uses the GIL on the no-GIL build, it’s designed to switch back to the GIL automatically. So this is not a 2=>3 situation where non-compatible code breaks.

The main reason for the two different builds is to manage the unknown unknowns. Indeed, nobody expects the no-GIL to break things, but with such a big project, you can never be sure. ABI compat is tricky, and new extensions need to be compiled explicitly against it for it to work, so there is a need for the community embracing it.

Also, no-GIL compatible extensions will work on the old interpreter, so you don’t get in the situation like Python 3 code not working on Python 2.

In fact, Python code itself should not be affected and will work seamlessly on one or the other, albeit with threads limited to a single core with the GIL.

That’s the news I didn’t see coming. In “What’s the deal with CPython, Pypy, MicroPython, Jython…?” we talked about Python compilers, and I thought I did a pretty good job about listing everything that mattered. Well, the team behind LPython decided to take this list and .append() on it.

LPython is a new BSD 3 compiler that takes Python code and translate it for the following for LLVM, C, C++ or WASM. It doesn’t aim to compile the entire program, although it can, but rather, like numba and cython, to let you speed up numerical bottle neck. The benchmarks are very promising and the ability to switch between Ahead-of-Time and Just-in-Time very convenient, although you will still need the entire compilation chain installed on the machine. LPython likes raw Python code, so if you call a Python function inside your snippet, you must explicitly mark it as such with a decorator. So most will likely use it for very specific snippets.

I’ve been pitching the coming of the version 2 of Pydantic for some time, because I, and many people, use it a lot for data validation / schema definition, and the new version is much faster.

Yes, it came out as stable last month, but if you read