(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

His parents owned a record store in some Dutch town. First records, then CDs. A social shop where you would gather to listen to CDs to determine whether to buy them. His father's brother actually started the oldest record store in Amsterdam, Concerto. It still exists.

Then the world changed. Napster, CD-burners. Illegal downloading. (He himself was one of them). His parents stopped selling music in 2008. He himself got into engineering. He ended up in South Africa, doing workflow orchesration for radio telescopes. There he introduced Docker and containers. He gave a talk at Pygrunn about it in 2016.

While he was in the South African desert, in Sweden someone started the Spotify company. He actually had used a library ("luigi") made by Spotify in his telescope work.

He tried to get a job at Spotify and succeeded. So the kid who grew up in a record store now works at the company that reinvented how people listen to music.

It all started for Spotify with Java (jboss 5). They hated it. It was replaced with Python: the reason was that nobody hated it. 80% of the code became python. A lot was async: they used "twisted" in the beginning, later gevent and greenlets.

But the Python GIL (global interpreter lock) made multi-core impossible. So you needed to use multiple processes, each with their own overhead. They also didn't like the lack of type safety: they have 100+ services. Some of those problems are partially solved now, but at the time the switched back to Java. Partially it was cultural: they could hire quite some Oracle employees that knew Java.

Python was still used a lot, just not for the core services. Nowadays, Python is used a lot for machine learning. They have 950 Python services, 470 libraries. 180000 Python files in 7500 repositories. 322x FastApi, 272x Streamlit repositories. And still lots of luigi. Luigi is the framework that inspired airflow: it has lots of starts on github, the most of all their open source repositories.

They now also started pedalboard, a nice Pythonic way of modifying audio (it is a wrapper around a c++ library). Also nice: https://backstage.spotify.com/ , a backend/portal for collecting all the developer-related data. Workflow statuses and so. (The backend is open source, the dashboard not).

At Spotify, the programmers are really encouraged to use agentic programming. He hasn't touched his editor in the last six months! It really changed his life. Initially he was a bit depressed: can someone who's less talented but with the same amount of tokens really do the same as me? But it is really a next level and he gets amazing productivity out of it. Having unlimited tokens helps.

It changes open source. Forking used to be a declaration of war. Nowadays it is a sign of popularity. You can fork something and have AI keep it up to date with minimal engineer effort. When the cost of maintaining your own fork approaches zero, what does that do with the economics of open source? Is cooperation still a thing? What is the goal/effect of open sourcing? Or is it only a way for AIs to find security bugs in your software?

His parents ran a record store for 42 years. Then technology disrupted the music industry. They had to reinvent themselves. It was scary and sad, but they adapted. Now the same force is disrupting our industry. Where will it go?

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

When automating in a big company with many systems, you often end up with spaghetti: many systems connecting to a lot of the others... A common solution is to have a "bus architecture". Generic existing "enterprise service bus" solutions were clearly overkill, so he proposed an alternative solution.

He made a couple of assumptions/choices. All data is tabular data. He wanted to store a copy of data in a database. SQL views to access the data. So: multiple sources that he wanted to import in a central database (which would function as a sort of "read-only enterprise service bus"). And a generic sql/view-based way of accessing the data.

He initially focused on read-only data. And he started real simple. Just a bash script that ran regularly that scraped data from other systems and injected it in the database.

In the second version of the system, for every system he wrote a target/command in a Makefile. Every thing that needed to be scraped got its own table (called a "list" in his system"). Lists could be compared. The first killer app was a comparison between a telephone list and the list of employees so that differences could be consolidated.

For the third version, he started using more and more python. CSV file imports. Downloaders from REST APIs. All configurable so that he could use the same python script for many different sources.

He now had a simple sytem for which he could write views and exports.

• Publishing data on the intranet via the "jekyll" static site generator. For instance a "mug book" of all employees.
• And regularly exporting a list of names+emailaddresses in a format suitable for the multifunctional printer: to make it easy to select your email address when scanning on the printer.
• An export to a google spreadsheet that combined the holiday spreadsheet with the data on part-time days.

Security was handled with a role-based system.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Subtitle: a real-world journey from chaos to confidence using Pydantic and Pytest.

Idealy, you'd have perfect json files with a fixed format and rigorous validation and ideally generated. But in a customer project, the other programmers weren't too happy about it. They had massive JSON files, partially manually crafted. Some where just one single line and others were vertically aligned. And perhaps someone depended on the specific format for some "sed" or "awk" hacking... So whatever happens: it works, don't touch it.

The freedom trap. No schema means no contract. No contract means no trust. Fields accumulate, nobody removes them: "someone might be using it". Multi-team challenges: not everyone has the same skillset.

He wanted a different future: a trusted future. Validated and tested and formatted.

Pydantic is a python library for data validation using Python type annotations. You can define a data model with type hints. it will automatically validate and parse data according to those models:

from ipaddress import IPv4Address
from pydantic import BaseModel

class Server(BaseModel):
    hostname: str
    ip: IPv4Address
    ...

Make sure to look at pydantic-extra-types, they have lots of handy types like "two-character country code".

There's AfterValidator, you can use it to add a second validator to a field. So first the str type to validate it is a string, then afterwards some ip address validator or so.

Understanding the data is important. Split it up in smaller pieces and try to understand/model/validate those. Especially in a corporate setting, splitting up the problem is handy: you have some small success you can mention at the standup :-)

Do it iteratively. One piece at a time. If you find a problem, create a ticket for it. It might not get fixed, but at least you end up with a list you can slowly tackle with the rest of the organisation.

A good tip: if you discover an error in the data, provide a good, clear error message that your colleague can understand.

When you export the data, use model_dump(exclude_optional=True) to exclude all the optional fields instead of having it as my_field: None.

Bonus: you can call YourModel.model_json_schema() to generate a JSON schema for the Pydantic model. You can then use the JSON schema in vscode when you manually edit your JSON.

Pydantic is great at validating individual fields and structures. But not at validating things that span the entire document, like making sure that all hostnames are unique. He used Pytest for it: he wrote such validation checks as pytest functions!. You can even use Pytest test parametrization to run the same test on multiple directories.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Full title: how to store and route your (physical) mail like a pro - personal edition.

How do you deal with your mail? Your physical mail? How do you store it? If the tax people want to have some information, can you find it, for instance?

Bart's motto is there must be a better way. So what is the pragmatic approach to better physical mail handling? A mail handling system that is flexible, automated, searchable and easy to use.

He discovered paperless-ngx, an open source document management system that allow you to store, organize and search your documents. Web interface, api, it can also read emails (via the "gotenburg" plugin). It can watch folders for new docs to process. It has features for structuring, self-improving (without AI). Tags. And you can have workflows.

Nice. Documents can go to Paperless. But he still has his bookkeeping system (he has his own company). And the bookkeeper wants emails with documents that are in Paperless. Can he improve this? For instance for receipts. He didn't want to scan all of them to PDF. And regular phone cameras don't produce PDFs.

He started using "dropbox camera". It works great for scanning receipts and documents. It recognizes corners and pages and enhances the contrast. It produces PDFs and uploads them to dropbox. (You must accept the fact that it ends up in the cloud: he build all this pre-Trump...)

He has a Synology NAS at home. That has a CloudSync app that you can use to sync the dropbox folder to the NAS.

He wanted to make some python glue gode. Ability to send to multiple destinations. Process folders for new files. Moving files to a "done" folder. Python looks at the various folders: he configured a specific custom "processor" per folder. So a move-to-paperless processor, for instance. And a processor that emails the scanned receipts directly to the bookkeeper.

Lots of it is automated. Just drop a PDF in a folder and the system takes care of it. Once in a while he checks Paperless and categorizes/stores what's left in the inbox.

It was a personal project, so he used it to experiment with Dataclass and Protocol. Don't forget to learn when you create/automate something for yourself.

He finds it awesome that something this easy saves him hours! What can you automate in your life?

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Full title: layered architecture for readable, robust, and extensible apps.

Note: there's a related article on his own website :-)

Layered architecture resonates with people that make okay applications: their application do what they need to do. But once people start asking for changes, they get nervous. There might be huge functions. Or there might be no tests, "as it takes too much time to spin up the database". Brittle applications. Small changes are disproportionally expensive.

The goal of this talk: create apps that are readable, robust and extensible. By using the principle of separating everything in layers with a specific responsibility. It is not a one-size-fits-all solution: you have to adapt it to your situation.

The layers that he proposes:

• Interface: how the ouside world calls your application. An API or UI.
• Infrastructure and Repository: your contact with the outside world (like a database).
  • Infrastructure is tools. A http client. A mail sender.
  • Repository: persistence. SQL queries, caches. The aim is to decouple the rest of the system from db/cache/etc.
• Application: heart of your system, orchestrating the business logic. The Interface talks to the Application layer, the Application layer talks the infra/repo. And uses the Domain layer.
• Domain: constraints and definitions. He often uses Pydantic models here. It reflects the business meaning. It should be strict. Fail early. The "language" used should be a shared language between the engineers and the business people.

There are some rules, like the Interface only talks to the Application, not directly to the Infrastructure. And your code should be structured the same way. So a repo/ dir, an infra/ dir etc.

What are the benefits?

• It is more readable, you know where stuff is. This also helps with onboarding.
• It is more understandable, also to business people.
• Your app will be much more maintainable.
• Structure is clearer.
• Because you have more separation between concerns, validation is easier, so you tend to do more of it.
• Evolvable. You can build upon your existing code instead of modifying it.

How to get started?

• Start with separate directories. If you wonder where a function should go, it probably has too many responsibilities :-)
• Add tests.
• Start small.
• Focus on validation. Fail early.
• Isolate the business logic.
• Concentrate on the borders and separations.

Something to watch out for is making your models too big. You might have to split it into separate systems with their own responibility. A payment system, separate from the inventory system, for instance. You might want to create a small, focused shared domain system.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

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

python -X importtime manage.py check

Djangofmt, a Django template formatter written in rust - Thibaut Decombe

Djangofmt, a fast, html aware, django template formatter, written in Rust.

https://github.com/UnknownPlatypus/djangofmt

You can run it as a pre-commit hook.

Unrelated photo explanation: a cat I encountered in Athens in the morning near the hotel.

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

Full title: what's in your dependencies? Supply chain attacks on Python projects.

How supply chain attacks work: attackers don't attack your code directly, they target something you trust. A typical Django project has lots of dependencies. Direct dependencies and "transitive dependencies", dependencies of our dependencies. If you depend on requests, requests itself will grab certify and urllib3.

Possible package attacks:

• Inject malicious code directly into the repo.
• Create malicious package. Typosquatting (abusing typos), slopsquatting (abusing typos made by LLMs). "Brandjacking": quickly after deepseek became popular, a deepseekai package was published that stole credentials.
• Compromise existing package. Credential stealing, CI/CD exploits.

What attackers typically do with access is to steal credentials. Environment variables, cloud keys (AWS_xyz), pypi tokens, ssh private keys, database URLs, saved passwords.

Example: num2words was hacked in July 2025. Phishing leading to maintainer credentials theft. Fake login page at pypj.org instead of pypi.org. Then they uploaded faulty releases with the captured credentials. Credentials weren't rotated, so a second attack happened a few days later. This malware targeted .pypirc files, leading to more compromises.

How can we defend from this kind of attacks? Depends on the kind of attack. When publishing via GitHub actions, use "trusted publishing", in that case there are no credentials to steal.

Another example: LiteLLM was compromised via trivy, a security scanner that itself was compromised... It in turn collected environment variables, secrets and ssh keys, bundled it all in a tarball and posted it to some legitimate-looking domain.

Some myths:

• "Lockfiles protect us". No, they only prevent accidental upgrades, not when adding a package for the first time.
• "Just don't install suspicious packages". Lots is installed via transitive dependencies.
• "We run everything in Docker so we're safe". It limits the blast radius, but credentials and environment variables are still at risk.
• "We can fully prevent attacks".

Some tips:

• Use dependency cooldowns. uv has "exclude-newer", pip has "uploaded-prior-to". Don't be the first to install a fresh release, as most malicious packages are discovered within hours or days.
• Pin versions and verify hashes.

Pypi is getting better:

• Trusted publishing.
• Project quarantine.
• Attestations: cryptographic tools to verify the source.
• Typosquatting protection.

AI has risks:

• Slopsquatting. Hallucinated package names that get exploited.
• Prompt injection via github issues.
• Agents often "just" pip-install things directly.

Note: AI can also be used to detect malware! A small project started after the LiteLLM compromise managed to detect a dangerous different compromise almost the moment it was published. Nice!

Unrelated photo explanation: a cat I encountered in Athens on an evening stroll in the neighbourhood behind the hotel. It was a cat on the hunt: relevant to the topic of this talk :-)

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

It all started with formsets: you generate a new form based on other forms. You can use it to create pretty fancy forms. But your designer can get quite creative. And you might have variable forms that have to react to user input.

A common solution is to use htmx, but that means server requests all the time. And some users have really bad connections. Regular requests aren't handy in that scenario.

He looked at django-rusty-templates: Django's template engine implemented in Rust. It had a template parser that he could re-use. With OXC (javascript oxidation compiler) he converted that to javascript.

That way, he could offload much of the django form creation handling to the frontend, including reacting to user input and showing alerts.

The work-in-progress project is called django-template-transpiler: https://github.com/christophehenry/django-template-transpiler . Don't use it for production.

Unrelated photo explanation: a cat I encountered in Athens on an evening stroll in the neighbourhood behind the hotel.

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

She works at Cosine, they develop measurement systems and space instrumentation. They work for the space industry (ESA, NASA, etc).

They're now working on "high-energy optics", the NewAthena x-ray observatory, the biggest one to date. NewAthena: NEW Advanced Telescope for High-ENergy Astrophysics. Planned launch is in 2037 on Ariane 6.4.

Talking about rocket science is cool, but where's the software? Within the company, software is an internal service, supporting scientists. Handling data in many ways: visualization, analysis, processing, management. Django plays a big role in all of this.

When you build something with Django in a scientific context, you really need to understand the data. Workflows must be flexible. R&D and production often don't need to be strictly separated. Multiple datastores for various purposes (like an extra MongoDB, for instance) is often handy.

Their application consists of:

• SXRO (silicon x-ray optics) database.
• A Mysql database.
• Django.

The goal is to track all the components that go into the observatory. Status and quality. Configuration and geometry. Component relationships. Inspections. History of all the components.

The default Django admin is their primary method of using the application. Often, it is said that the admin is not not not intended for end users. But they're using it anyway. It is an internal tool for technical people. Most of them have a PhD: they can handle such an interface. They've been using it for years.

There are some third party packages:

• django-simple-history: easy history.
• djangoql: advanced queries for the search bar.
• django-admin-rangefilter, django-admin-list-filter-dropdown, django-admin-numeric-filter: little tools to tweak the filters on the right hand side.

There are some separate forms, mostly for actions performed in the lab or cleanroom. For instance a form where you can use an ipad to indicate defects in one of the components by just drawing on the picture of the component.

There's also a REST API. Other software and data tools can use it to integrate with Django:

• Observability tools (prometheus/grafana).
• JupyterHub.
• Stacking robots.

They use: djangorestframework, drf-spectacular (API docs), django-filter (filtering via GET parameters).

Django is their software backbone. A general-purpose framework that's well suited for a scientific context.

Unrelated photo explanation: a cat I encountered in Athens on an evening stroll in the neighbourhood behind the hotel.