Djangocon EU: static islands, dynamic sea - Carlton Gibson¶

Tags: django, djangocon

(One of my summaries of the 2026 Djangocon EU in Athens).

PEP 484, about type hints: Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, not even by convention. Well, that last part seems to be be a bit more nuanced nowadays.

Dynamic sea

Django does not have type hints. Django predates type hints. But as Django and as a Django add-on author, you encounter lots of pressure to “just” add it. What about the “not even by by convention”? Django has 20+ years of keeping the dynamic stuff in check. Experience in validating, in cleaning inputs.

And it uses conventions: everyone knows that a view takes a request and everyone knows what it does. According to Django’s design philosophies: Django should take full advantage of Python’s dynamic capabilities. It should reduce boilerplate, by using Python’s dynamic possibilities to its advantage.

Conventions are handy and can be build into editors. But the editor’s work is made easier with type hints: you now have three LSP, language servers, that can use the type hints to give you feedback. Hence the popularity.

But is it still powerful, dynamic Python when we enforce type hints everywhere? The code starts to look ugly with all the boilerplate. And if we want a statically typed Django, you should write it in Rust, without all the nice dynamic stuff and without the elegance…

Static islands

Does Carlton hate type safety? No, actually not. He likes to introduce Django mantle, a type-safe layer around Django’s core.

The ORM can be mis-used. A Model class can quickly grow a lot and gain extra methods. And if you grab data from the database, you by default grab all the fields, even the ones you don’t use. And perhaps you grab a list of objects, iterate over them and then call a related field on them: the familiar 1+n problem, lots of extra queries.

A solution would be to exactly specify what you want (with type hints):

from attrs import define  # Note: attrs is "dataclasses+extra functionality"

@define
class BookmarkData:
    id: int
    title: str
    favourite: bool

Django matle allows you to do such a targeted query, mixing a regular Django query with such an attrs class (mostly like a dataclass):

from mantle import Query

query = Query(
    Bookmark.objects.filter(xxx=yyy),  # Actual Django query
    BookmarkData  # Attrs thing to return
)

The result is one query, even when there are related fields. And you get a list of nicely focused BookmarkData items.

He has different integrations, for instance for validators. And there’s a Django rest framework integration.

Static or dynamic

Trick question: we should use both. Django is powerful because it uses the dynamic powers of Python. And it is readable and clean. Let’s not use that!

On the other hand, type hints are very nice. We can make a good separation between dynamic Django and the pieces of our own code where we want to use type hints.

Question from the audience: can you compare it with pydantic?. Many people think Django’s main problem is the coupling of validation, serialization etc in the ORM layer. Pydantic actually wants to couple those same things, too, only in a different way. So why switch? He actually wanted to get a better separation.

Unrelated photo explanation: a recent trip to the “Modellbundesbahn” in Germany. A big series 44 goods locomotive on display in Altenbeken.