What’s up Python? New record type, new JIT perfs, new Python rest lib...

All new baby

Summary

Yes, yes, OpenAI bought Astral. We know. There is already an article dedicated to that.

In other news:

• Core dev Brett Cannon published a PoC for a new Python record type

• The Python JIT is finally producing better perf

• A new take on Rest API with Python: django modern rest.

Brett Cannon’s PoC for a new Python record type

Last June, Brett Cannon published a proposal to introduce a new struct object in Python. I liked the idea because when you are on a Python code base with a lot of type hints, you have to declare a ton of disposable types you will use only for a single function. This is making such a situation less of an ordeal.

But it had a drawback: a new syntax and a new keyword. Two things that are quite hard to introduce to the project.

So Brett came back this month with a lib to create a record type that you can find on pypi.

Now brace yourself, the syntax is weird:

>>> from records import record
...
... @record
... def InventoryItem(name: str, price: float, *, quantity: int = 0):
...     """Class for keeping track of an item in inventory."""
...
>>> item = InventoryItem("Bread", 4, quantity=2)
>>> item
InventoryItem(name='Bread', price=4, quantity=2)
>>> item.name
'Bread'

Yes, you read that well, we have a decorator on a function with camel case that gives us a constructor we use to generate the object, like a class would do.

It’s a proof of concept.

But it shows we can have a short typed definition for an object that requires no body to run, that explicitly says it’s not meant to be inherited, and that is immutable and hashable.

In fact, it defines __slots__ , __match_args__ , __annotations__ , __eq__() , __hash__() and __repr__() automatically. It’s more or less the equivalent of:

from dataclasses import dataclass, KW_ONLY

@dataclass(frozen=True, slots=True)
class InventoryItem:
    """Class for keeping track of an item in inventory."""
    name: str
    price: float
    _: KW_ONLY
    quantity: int = 0

Which is much more verbose.

I still prefer the struct proposal, which would give you:

struct InventoryItem(name: str, price: float, *, quantity: int = 0)

It’s even shorter; the keyword makes it clear it’s meant to be an immutable record, and potentially, it could be inlined as a return value type hint. Something we know from PEP 764 (inlined typed dicts) is interesting to a few people already.

Django Modern Rest, an interesting take on APIs

The Python world is rich with options to create Web API. FastApi is super popular, Django Rest framework is surprisingly still very much used, and Django-ninja has gained in popularity over the last year.

Well, a new contender joined the party: Django Modern Rest.

Like django-ninja, it takes inspiration from FastAPI type hint introspection to create a similar look and feel in Django, albeit using class-based views instead of functions.

But instead of only supporting pydantic models to define your endpoints’ schema, it also supports attrs and msgspec.

The latter is the selling point of the framework, because this library claims it is capable of parsing AND validating JSON faster than orjson (one of the fastest JSON parsers out there) can just parse it. On top of that, it also supports MessagePack for micro services.

I haven’t verified those claims, and the framework is a bit too new for me to try it out in a serious project just yet. Not to mention my code is usually I/O bound, generally by the DB queries, so I’m not sure how much I would get by adopting this.

But the project philosophy is clear, API makes sense, and the docs are nice, so I’m going to keep an eye on it.

The new JIT is finally Jitting

For several versions, Python came in with a built-in Just In Time compiler similar to Pypi. So far it was touted mostly as infrastructure work, without producing much performance improvement.

It was expected to be harder to get massive gains from it, because of the additional constraints of needing to support C-extensions and not slowing down startup time for small script.

But it finally happened, the Python 3.15 alpha JIT is now officially about 11-12% faster on macOS AArch64 than the tail calling interpreter, and 5-6% faster than the standard interpreter on x86_64 Linux.

You won’t get those perf gains for all workload as they are average over many tasks, which can show from 20% slowdowns to doubling the speed, so your mileage will vary, but it’s still some pretty good news considering they are adding up to the few gains of the last Python versions:

• 3.11: +25–30%

• 3.12: +3–7%

• 3.13: +2–5%

• 3.14: +5–10%

If we add 10% on top of that, we compound to 60% faster in 5 years. Far away from the 500% initially desired, but still significant.

But apparently, even those results were very hard to obtain:

I cannot overstate how tough this was. There was a point where I was seriously wondering if the JIT project would ever produce meaningful speedups. To recap, the original CPython JIT had practically no speedups: 8 months ago I posted a JIT reflections article on how the original CPython JIT in 3.13 and 3.14 was often slower than the interpreter. That was also around the time where the Faster CPython team lost funding by its main sponsor.

And Moar

• Django ninja, my current go-to for creating Web API, landed SSE support.

• I just discovered formualiazer, a Rust and Python engine to manipulate spreadsheets that can parse, evaluat,e and mutate formulas!

• HTTPX and MKDocs’ author is worrying the .

• Velxio 2 is out to let you emulate Raspi and Esp32 in the web browser. And yes, you can simulate attaching components to GPIO and run Python code.

• Python 3.14.3, 3.12.13, 3.11.15 and 3.10.20 are available.

• Python 3.15 alpha has been released, should you want to test it. But lazy imports are not in there yet.