Python News: What's New From October 2023

Python 3.12 Released

The latest version of Python, Python 3.12, came out on October 2. You can read more about the release in last month’s newsletter.

If you haven’t tried Python 3.12 for yourself yet, then you should give it a quick spin! Especially if you’re working on a library or an application, it’s good to check that it works on the latest version of Python. You can install several versions of Python on your computer to try them side by side.

The biggest challenge with upgrading a project to a brand-new version of Python is that some of your dependencies may not be ready yet. In general, pure Python libraries should continue to work well, while you may experience issues with extension modules that need to be compiled especially for Python 3.12. However, most of the popular libraries are on the ball and are providing compatible wheels already.

Python Enjoys New Developments

Even though Python 3.12 has just been released, the core developers have been working on Python 3.13 for several months already. You can expect the next version of Python to be released in October 2024.

The first alpha version of Python 3.13 is now available. As it’s still early in development, you won’t find many new features yet.

Instead, the main differences between Python 3.12 and 3.13 so far are deprecations and removals of old functionality. In particular, the dead batteries identified in Python 3.11 have now been removed, and many private functions in Python’s C API have been removed.

There are several places where you can follow the discussions and work that goes into developing and maintaining Python, including GitHub, discussion forums, and PEP documents. Last month, core developers Pablo Galindo Salgado and Łukasz Langa unveiled a new platform for Python news: a podcast named core.py.

In the first episode, Pablo and Łukasz discuss some of the features that are in development for Python 3.13. These include an improved editing experience in the REPL and the Faster CPython project’s just-in-time (JIT) compiler prototype.

In the second episode, they cover PEP 703 and the road toward a version of Python without the GIL. The GIL—or global interpreter lock—is a mutex that ensures that only one thread accesses the Python interpreter at a time. A GIL has several advantages in single-threaded programs. However, it also makes parallel processing harder.

If you’re interested in everything that happens under the hood in Python, then you won’t find better guides than Pablo and Łukasz. They’ve both been instrumental in several of the recent new features of the language. Additionally, Pablo was the release manager for Python 3.10 and 3.11, while Łukasz had the same role for Python 3.8 and 3.9.

Steering Council Accepting Nominations

Python has relied on a steering council for governance since Guido van Rossum stepped down as the sole decision maker in 2018. The steering council consists of five members who are elected for one year at a time.

Currently, the fifth steering council consists of Brett Cannon, Emily Morehouse, Gregory P. Smith, Pablo Galindo Salgado, and Thomas Wouters. Nominations are open for the sixth steering council, and voting will happen during the last two weeks of November.

Anyone is eligible as a candidate for the steering council, but a core team member must nominate them. Only Python core team members are eligible to vote. The results of the election should come out in early December.

PEP 703 Accepted: One Step Closer to Python Without the GIL

Removing the global interpreter lock (GIL) from Python has been discussed throughout the lifetime of the language. Sam Gross first announced his nogil project in October 2021, and the proposal was broadly discussed at the Python Language Summit in April 2022.

Since then, a formal proposal was written in January 2023. PEP 703, Making the Global Interpreter Lock Optional in CPython, lays out the motivations for removing the GIL and adds detailed specifications for how to proceed.

After a lively discussion, the steering council announced their intention to accept PEP 703 in July 2023. In a recent post, the steering council confirmed that they accept PEP 703.

While the future of Python looks GIL-less, the acceptance comes with certain expectations:

In short, the SC accepts PEP 703, but with clear proviso: that the rollout be gradual and break as little as possible, and that we can roll back any changes that turn out to be too disruptive – which includes potentially rolling back all of PEP 703 entirely if necessary (however unlikely or undesirable we expect that to be). (Source)

Additionally, the steering council suggests that the new build will have a more descriptive name. The term no-GIL refers to what will be absent in the future version of Python. While this has been helpful so far, it’ll be better to describe what the new version will do. They suggest using the term free-threading instead.

The implementation of PEP 703 is expected to take several years, and it’ll happen in three separate phases:

1. The experimental phase, which has already started
2. The supported-but-not-default phase, where most of the necessary API and ABI changes have been done, but the current GIL version of Python is still the default
3. The default phase, where the new free-threaded build becomes the default in Python

The announcement is deliberatily vague about when the second and third phases will begin. The core developers and steering council will work out timelines later as everyone gets more experience and better understands the impact on the ecosystem.

PEP 723: Embedding Dependencies in Single-File Scripts

Improving packaging and deployment of Python projects is a long-term, ongoing effort. Over the last couple of years, pyproject.toml has emerged as a standard for defining project metadata using the TOML format. In the file, you can specify information about your library or application, including which other libraries it depends on.

Sometimes, you’re working with a single-file script that does some job. Such a script is often a simple, yet powerful, solution to some challenge. One advantage of these scripts is that they’re often quick to share with colleagues, who only need to copy the file into their Python environment.

If your script depends on third-party libraries or a specific version of Python, then the situation is more cumbersome. Your friend needs to both copy the script and create a new virtual environment with the necessary dependencies. Currently, the best way of specifying the dependencies is to create a pyproject.toml file, but then you need to share two files.

PEP 723 specifies how you can embed information about the environment directly into the script file. Instead of using a separate file, the TOML-formatted information will appear in comments at the top of the script. The following example is from PEP 723 itself:

# /// pyproject
# [run]
# requires-python = ">=3.11"
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()
pprint([(k, v["title"]) for k, v in data.items()][:10])

This example uses the third-party libraries Requests and Rich. The comment block on top of the script shows the syntax that this new PEP introduces.

The marker # /// signifies that these comments have special meaning. So far, only one such type of comment block has been defined, namely pyproject, which you can see here. Inside a pyproject block, you may use two different TOML tables: tool and run.

You may use the tool table to configure a script runner or another tool. This PEP doesn’t prescribe how to specify such a configuration but leaves it up to the individual tools. The other table will contain information about the environment that the script should run within:

• dependencies is a list of strings enumerating the necessary dependencies of your script.
• requires-python is a string specifying which versions of Python your script is compatible with.

Both of these fields are optional.

No tools support these new comment blocks yet. However, the PEP has been accepted. Several tool maintainers have expressed support for the new syntax. Therefore, you can expect several tools to implement it soon.

PEP 729: Establishing a Typing Council

PEP 729 is a new proposal that suggests establishing a Typing Council. The council will be responsible for maintaining and developing the Python type system.

Type hints have been available since Python 3.5. Python’s type system was initially specified in PEP 484 but has evolved considerably since then. Every modern Python release implements several new typing-related PEPs.

The current approach for developing the typing ecosystem has served the language well so far. However, it also has some shortcomings, which PEP 729 recognizes:

• PEPs are the only specification.
• It’s hard to evolve the specification.
• The type system is underspecified.
• The steering council isn’t well positioned to solve the above problems.

PEPs, or Python Enhancement Proposals, are official documents that the Python Steering Council either accepts or rejects after a lengthy discussion. Typically, an accepted PEP is frozen and never gets amended later. Instead, changes to an existing PEP require a new PEP.

Currently, there’s no single, comprehensive specification of Python’s type system. Instead, you’d need to read through a long list of typing-related PEPs to get a full overview. Part of the responsibility of the proposed Typing Council will be to create and maintain a specification of the type system, as well as a user-facing reference guide.

If established, this council will advise the steering council on typing-related PEPs. It’ll also be able to make smaller changes to the type system directly. The Typing Council will consist of five members and be accountable to the Python Steering Council.

PEP 732: Establishing the Python Documentation Editorial Board

In 2021, the steering council approved the creation of a Documentation Work Group. The group has since been renamed to the Documentation Editorial Board and will oversee the Python documentation.

The mandate of the Editorial Board is the following:

• Ensure processes are in place to maintain and improve the quality of Python’s documentation
• Foster Python documentation as a community resource to serve the current and future users
• Act in alignment with the Python Software Foundation mission, which is to advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers
• Ensure that contributing to documentation is accessible, inclusive, and sustainable
• Establish appropriate decision-making processes for documentation content
• Seek to achieve consensus among contributors prior to making decisions
• Be the final arbiter for documentation content decisions (Source)

The PEP is currently under discussion, so some changes to the text will probably happen before it’s final.

Register for the First PyLadies Conference

PyLadies is a global group that aims to involve more women in the Python open-source community. There are many local PyLadies chapters around the world, hosting local workshops, meetups, and other events.

From December 1 to 3, the first PyLadies conference will be held online. There will be talks in English, Spanish, and Portuguese, including keynotes by Sophia Yang, Jimena Bermúdez, Marlene Mhangami, and Thais Viana.

Registering for the conference is free, and you can do so on the conference website. You can also preview some of the scheduled talks.

PyCon US 2024 Opens Call for Proposals

PyCon US is the largest annual gathering of Python developers. In 2024, the conference will take place in Pittsburgh, Pennsylvania, from May 15 to 23. The main conference happens from May 17 to 19, and it follows two days of tutorials and precedes four days of sprints.

The last edition of PyCon US was held in Salt Lake City, Utah, in April 2023. The conference featured more than one hundred talks and tutorials that you can now watch online.

If you want to take part in next year’s PyCon US conference, then you should have a look at the call for proposals, which is now open. You can propose a poster, a tutorial, or a talk—in either English or Spanish. The call for proposals closes on December 18, 2023.

Presenting at PyCon is a great opportunity to share your experiences and expertise. If you want to submit a proposal, then you can also take advantage of PyCon’s mentorship program. This means that you’ll be paired with an experienced mentor who can help answer questions that you may have about your proposal. Your mentor will support you in compiling the necessary information.

What’s Next for Python?

Python reached a new milestone with the release of Python 3.12 in early October. Still, the community doesn’t rest, and there are several important initiatives to establish governing groups focused on typing and documentation.

If you’re itching to get out and spend time with the larger community, then joining a conference might be what you’re looking for. Register for the first ever PyLadiesCon or submit a proposal for a talk to PyCon US.

What’s your favorite Python news story from October? Let us know in the comments. Happy Pythoning!