What's up python? Less perf, no sugar and more bugs

March, 2025

Summary

• The shorthand syntax for keyword arguments at invocation has been rejected.

• Python 3.14 perfs were not that great after all

• Setuptools deprecation breaks things

• The new Python lock format is ready

• Dependabot now supports uv

PEP 736 is rejected

PEP 736 introducing the shorthand syntax for keyword arguments at invocation has been rejected.

The proposal suggested syntactic sugar to pass a parameter to a function that has exactly the same variable name and argument name.

E.G., you could write this call:

sign_in(username=username, password=password, otp_code=get_otp())

In a shorter way:

sign_in(username=, password=, otp_code=get_otp())

This has both the benefit of avoiding tedious repetition and highlighting the things that don't repeat.

It's something JS has had for some time, albeit indirectly through object destructuring and the convention of passing full mappings to functions:

signIn({ username, password, otp_code: getOtp() });

Rust has something similar for structs and Ruby keyword arguments allow to do:

sign_in(username:, password:, otp_code: get_otp)

This is something I miss in Python, both for passing values and unpacking dictionaries.

However, I was never sure this particular PEP syntax was the way to go, it looks like a syntax error at first glance, and there is something eerie about it.

In its rejection statement, the Steering Council echoes this:

the SC is not convinced that this feature is the best that Python can provide. While we recognize that solutions like this can improve some use cases, they need to be properly balanced with everything else. As we have mentioned in previous occasions grammar changes are subjected to higher scrutiny levels given how far they reach.

I'm not going to turn all my API into **kwargs so I guess I'll keep walls of repeating arguments in my programs for the time being. Explicit is better than implicit, I guess.

But for the record, I did want a pony.

Python 3.14 perfs were not that great after all

The last few releases of Python brought a lot of great things, but unfortunately, they didn't live up to the hype of the promised increase in performance.

It seems 3.14 will not be any different.

This version comes with a new optional tail-call interpreter that seemed to provide a 10 to 15% perf gain on average.

A tail-call interpreter is one that efficiently handles function calls that occur as the last operation before returning a result to avoid growing the call stack unnecessarily. It’s a delicate thing to implement in Python because the stack is expensive but also a very important part of the language: it’s exposed as a public API you can manipulate from your program itself, plus it’s what gives you the wonderful trace you get when the program crashes.

So there were a lot of expectations.

But while playing with it Nelson Elhage, a researcher at Anthropic, noticed something was off.

When benchmarked against GCC or clang-18 the performance gain drops to 1-5%. It turns out the gains were mostly due to inadvertently working around a regression in LLVM 19.

It's not all bad news, of course.

First, we still have a few percent of speed up. Second, a bug was noticed, and fixed. Lessons were learned and benchmarking improved. And finally, the new interpreter still has the potential to deliver more in the future.

It's a bad season for ponies though.

Setuptools deprecations break things

Setuptool 78.0.1 finally removes support for metadata keys using dashes in their name instead of underscores. This has been deprecated since 2021, but projects using setuptools instead of more modern build systems are probably the ones less likely to update their toolkit often. Not to mention it was easy to miss.

And so now, stuff break.

So if you get setuptools.errors.InvalidConfigError: Invalid dash-separated key, either downgrade setuptools, change the name of whatever key you are using or switch to a dependency that does that in case you are not in control.

Also, consider moving to hatchling which uses pyproject.toml to store the config, is fully declarative, faster, and has better build isolation.

Or don't. I still have a few projects using setuptools and they work fine.

And if you don't know what I'm talking about, I'll probably write a series of articles on packaging one day.

The new Python lock format is ready

Forgot that one (which is ironic considering I’ve been following it for months), so I’m adding it post-publication.

PEP 751, the never-ending battle of Brett Canon (Interview coming soon, I promise, I’m just late on my lateness) to define an official lock file for Python, is finally over. The goal is to provide a file format that can list all dependencies of a project, and their associated information so that someone can reproduce exactly the same environment on another machine.

A lock file is not just a list of what your project requires directly. It is also a list of what your dependency requires themselves, their exact version, where to fetch things from, plus a bunch of other metadata that matter when you want to get things right. requirements.txt can be used as a (crude) lock file, pyproject.toml cannot.

It’s a huge achievement because there are currently 5 competing formats from PDM, pip, pip-tools, Poetry, and uv; which all come with trade-offs.

The spec is quite heavy but here is the provided examples (read this one if you can, it has colors, substack doesn’t):

lock-version = '1.0'
environments = ["sys_platform == 'win32'", "sys_platform == 'linux'"]
requires-python = '==3.12'
created-by = 'mousebender'

[[packages]]
name = 'attrs'
version = '25.1.0'
requires-python = '>=3.8'
wheels = [
  {name = 'attrs-25.1.0-py3-none-any.whl', upload-time = 2025-01-25T11:30:10.164985+00:00, url = 'https://files.pythonhosted.org/packages/fc/30/d4986a882011f9df997a55e6becd864812ccfcd821d64aac8570ee39f719/attrs-25.1.0-py3-none-any.whl', size = 63152, hashes = {sha256 = 'c75a69e28a550a7e93789579c22aa26b0f5b83b75dc4e08fe092980051e1090a'}},
]
[[packages.attestation-identities]]
environment = 'release-pypi'
kind = 'GitHub'
repository = 'python-attrs/attrs'
workflow = 'pypi-package.yml'

[[packages]]
name = 'cattrs'
version = '24.1.2'
requires-python = '>=3.8'
dependencies = [
    {name = 'attrs'},
]
wheels = [
  {name = 'cattrs-24.1.2-py3-none-any.whl', upload-time = 2024-09-22T14:58:34.812643+00:00, url = 'https://files.pythonhosted.org/packages/c8/d5/867e75361fc45f6de75fe277dd085627a9db5ebb511a87f27dc1396b5351/cattrs-24.1.2-py3-none-any.whl', size = 66446, hashes = {sha256 = '67c7495b760168d931a10233f979b28dc04daf853b30752246f4f8471c6d68d0'}},
]

[[packages]]
name = 'numpy'
version = '2.2.3'
requires-python = '>=3.10'
wheels = [
  {name = 'numpy-2.2.3-cp312-cp312-win_amd64.whl', upload-time = 2025-02-13T16:51:21.821880+00:00, url = 'https://files.pythonhosted.org/packages/42/6e/55580a538116d16ae7c9aa17d4edd56e83f42126cb1dfe7a684da7925d2c/numpy-2.2.3-cp312-cp312-win_amd64.whl', size = 12626357, hashes = {sha256 = '83807d445817326b4bcdaaaf8e8e9f1753da04341eceec705c001ff342002e5d'}},
  {name = 'numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', upload-time = 2025-02-13T16:50:00.079662+00:00, url = 'https://files.pythonhosted.org/packages/39/04/78d2e7402fb479d893953fb78fa7045f7deb635ec095b6b4f0260223091a/numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', size = 16116679, hashes = {sha256 = '3b787adbf04b0db1967798dba8da1af07e387908ed1553a0d6e74c084d1ceafe'}},
]

[tool.mousebender]
command = ['.', 'lock', '--platform', 'cpython3.12-windows-x64', '--platform', 'cpython3.12-manylinux2014-x64', 'cattrs', 'numpy']
run-on = 2025-03-06T12:28:57.760769

The file must be named pylock.toml or pylock.<something>.toml.

As expected it contains information about the OS, supports both wheels and sdist but also addressing local resources or a remote VCS repository.

More interestingly, it contains a hash for each file but also the upload time and expected file size for security reasons.

It is likely that not all tools will be able to support it as it can’t cater to everybody’s needs, but I’m confident most tools will at least provide an export option.

Dependabot now supports uv

Dependabot is a GitHub bot that checks if your project dependencies are outdated or insecure and alert you.

It's handy to keep your project up to date and act as a safety net for low-hanging fruits, especially since it costs close to nothing.

The fact it didn't support uv so far was not a problem in my eyes, because you could always uv export to a requirements.txt file that was supported, so it was always more of an inconvenience than anything else.

But I've seen several people in the wild reporting it was blocking for them, as this tool can also automatically create pull requests to update dependencies for you. Something I don't use, but I see the point.

So I decided to end this article with a positive touch: dependabot now officially supports uv.

Rejoice.