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

Full title: zero-migration encryption: building drop-in encrypted field in Django.

He works at Sentry. Huge site with a Django backend and thousands requests per second.

He had to add a new table to store 3rd party API credentials. Oh: should this be encrypted? Yes. But: each team has its own way to encrypt data. And there were at least 10 encryption keys here and there (as environment variables). And tens of places where encryption/decryption happens.

So: better to build a generic solution. Or use an existing generic solution. And yes, there are multiple libraries. EncryptedCharField looked nice. But the problem was all the existing data in the various places. Sentry is not a site that you can shut down for a while, so you have to do it with zero downtime. This means you can never change an existing column type.

A solution could be to add a new encrypted field next to the existing one. Then fill it and backfill it and make sure no new data is written to the old field and then you can remove the old field. But that's quite a job with all the different locations that had to be changed.

A Field class in Django has get_prep_value() and from_db_value(). Those are called before storing data in the database and after grabbing it from the database. You could create a new CharField-like field and start to encrypt values in get_prep_value and decrypt the other way.

You'd have to be able to recognise the old un-encrypted values. A solution: prefix encrypted values with enc:. Also key rotation can be handled this way, by including that in the prefix (enc:key2:).

But there's also a bjson field. They solved that by encrypting the json and writing a json to the database with the encrypted json in a field and also the encryption key info.

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).

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).

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).

Original title: improving one of Django's most used APIs - and it's not the one you're thinking of. (I'm using a more descriptive title for my blog entry.)

APIs are everywhere. Django rest framework, but also the models layer. And: manage.py runserver, he considers that an API. Everybody runs it. So: can we improve it?

"Runserver" doesn't sound the same as "devserver" or "rundevserver". It doesn't advertise that it is only intended for development. A name change could help there. But... Django really likes to be stable. It is probably too entrenched to change.

Production is missing a cohesive API. You normally run something like gunicorn myapp.wsgi 0.0.0.0:8000 --workers 4...

He tried to get improvements in. Since 5.2, there's a warning when you start runserver: "it is only intended for development". But you might miss it when you get lots of log messages. Other people complained about the extra two lines.

He started django-prodserver. pip install django-prodserver[gunicorn]. You can then run manage.py prodserver (and manage.py devserver, he snuck that in).

You have to add a bit of configuration to your settings file:

PRODUCTION_PROCESSES = {
    "web": {
        "BACKEND": "django_prodserver.backends.gunicorn.GunicornServer",
        "ARGS": {"bind": "0.0.0.0:8000",},  # add number of workers and so.
    },
}

Run it with manage.py prodserver web. You can add more processes, for instance for a background worker process.

It is the first version. He wants feedback, especially on the naming. manage.py prodserver web or just manage.py web? And manage.py worker? manage.py serve --prod?

Django isn't just a framework, it is a set of APIs. We can prototype new APIs in packages.

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).

Athens! The thinking industry started here. Athens is often the origin if you follow ideas to the source.

Here also Socrates was found guilty (280-221) for "corrupting the youth" on trumped-up charges. Though... he made it is job to be a complete nuisance: exposing everyone's hypocrisy and asking difficult questions. After the 280-221 vote he got to give a speech in reaction. After that, the vote on the actual punishment was 360-141 in favour of the death penalty. The speech must have been particularly irritating.

On to a different subject. He watched the recent launch of the NASA rocket that went to the moon. A marvel of technology. That was measured using body parts, being 322 feet tall. And the distance to the moon in miles. Why not the scientific meter and kilometer?

Plato already mentioned it. "Now take the acquisition of knowledge; is the body a hindrance or not, if one takes it into partnership to share an investigation". And "when the soul tries to investigate anything with the help of the body, it is obviously led astray".

0.098 km = 98 m = 98000 mm, a child can understand it. Pure rationality. But ask a Metric Martyr in the UK how many feet are in a mile and most of them won't know.

The world seems to be divided in two camps:

• Thinking, rationality, abstraction, unboundedness.
• Bodies, materiality, tangibility, being rooted.

Wouldn't Plato have loved a computer? Pure rationality, following its logic programming without fail?

What about those body-part-units? They're not that weird actually. They're rational Roman measurements:

• A mile is 1000 Roman paces.
• 1 passus = 5 pedes (feet).
• 1/12 pes (feet) = 1 uncia (thus: inch).

(Note: according to the Greek, Romans are only good for stealing Greek ideas, building roads and killing people.)

On to another aspect. Why is Django's documentation so good? Well, it has been prioritized from the start. It is complete, accurate, consistent, rational and well-structured: all Platonic values.

But Daniele also thinks the documentation is so good because it fits the human body.

The size has to be right. The limitations of our intelligence are the limits of our embodied intelligence. We can only grasp so much, mentally. A list can be too long. A page can be too long. If information is cut in too-small parts, you also can get into problems as you have to context-switch between pages too much. We tire mentally also because we tire physically.

The same applies to our body. Our hands and fingers can grasp objects. But it has to be of a certain size. Too big and we can't grasp it. Too small and our fingers can't pick it up.

We experience documentation in time and space. We move with it. How long have you been reading the Django documentation? "Where are you in the text?" We orient ourselves in text as if in a space or a building. We rely on the humanised rationality of structure. Sometimes you're in a building and it is clear where you have to go and in other buildings you feel lost.

Django's documentation is so good because of the quality of experience that it gives you. It is almost an embodied being that you can experience in space and time. Does it fit you? Do you notice it? The embodied nature of the work and intelligence that the Django community poured into the documentation?

Early Macintosh manuals had to explain new concepts and really tried to explain them in a human way. Scrolling being explained with help of an old book scroll, for instance. A floppy disk for storage as a floor plan of a building with a corridor and rooms.

Aldine Press (started 1494 in Venice) had a vision to print the old classics in a more accessible way. Books in the middle ages used to be big. And sometimes chained to the desk. Not really accessible. By printing them in smaller, lighter, more accessible formats, he wanted to make our "body of knowledge" more fitting to the human body.

You can see the bodily aspects of knowledge in our language:

• Seizing/taking: grasp, comprehend, apprehend, perceive.
• Measuring: ponder, weigh up, fathom.
• Body movement: jumping to conclusions, intuitive leap, stumble/trip
• Spatiality: understand, position

Mental space. When he asked a question of Russell Keith-Magee at a Django sprint, Russell would close his eyes and turn his eye inwards for a while. He would look at the Django codebase in his head and navigate it. Just like you yourself would navigate a city?

Being a programmer isn't so different from being a human with a body in time and space. Look at questions you might have as a beginning programmer:

• Which file or directory or window to be in.
• Where to expect the output.
• When to expect it.
• Where to enter a command.
• When to do something.
• In what order to do things.

And then look at an experienced programmer. They seem to know where they are. They know their way around. They can move smoothly.

Closing comment: there are some uncanny features in software nowadays. As a human, we are used to having limits. But nowadays we have infinite scrolling, doomscrolling. And edgeless, endless, virtual cloud resources. And LLM indeterminism. Those are not inherintly bad, but it is different from what we're used to. Is this still computing fit for the embodied mind?

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).

There's an example to experiment with here: https://dryorm.xterm.info/fetch-modes-simple

Timeline: it will be included in Django 6.1 in August.

The reason is the 1+n problem:

books = Book.objects.all()
for book in books:
    print(book.author.name)
    # This does a fresh query for author every time.

You can solve it with select_related(relation_names) or prefetch_related(relation_names). The first does an inner join. The second does two queries.

But: you might miss a relation. You might specify too many relations, getting data you don't need. Or you might not know about the relation as the code is in a totally different part of the code.

Fetch mode is intended to solve it. You can append .fetch_mode(models.FETCH_xyz) to your query:

• models.FETCH_ONE: the current behaviour, which will be the default.
• models.FETCH_PEERS: Fetch a deferred field for all instances that came from the same queryset. More or less prefetch_related in an automatic, lazy manner.
• models.FETCH_RAISE: useful for development, it will raise FieldFetchBlocked. And it will thus tell you that you'll have a performance problem and that you might need FETCH_PEERS

This is what happens:

books = Book.objects.all().fetch_mode(models.FETCH_PEERS)
for book in books:
    # We're iterating over the query, so the query executes and grabs all books.
    print(book.author.name)
    # We accessed a relation, so at this point the prefetch_related-like
    # mechanism ist fired off and all authors linked to by the books are
    # grabbed in one single query.

You can write your own fetch modes, for instance if you only want a warning instead of raising an error.

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.

(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).

He works on "steel-IQ", an open source modelling platform for steel decarbonisation. They knew that they couldn't run it as a web app because of strict security requirements at the end users. So they thought about distributing it as a Python library or as jupyter notebooks. But the users would probably mess it up, so an installable UI was needed.

Perhaps we can do it with django? The first working version was easier than expected. They used "Electron" to get an installable app that showed a web interface. You'd start django inside the process, wait until it responded and then show the web interface as usual.

So: electron + django + sqlite.

The actual Steel-IQ app is full of steel terminology. Not everyone has a blast furnace in the back yard, so he created a sample project that's simpler: https://github.com/ephes/desktop-django-starter

The components:

• Electron: main.js nodejs program.
• Django server.
• BrowserWindow: a chromium renderer, this is what the user sees.
• Django workers: for the background simulation work.
• Shared data layer: sqlite + filesystem. The sqlite database is also used by the DatabaseBackend of django-tasks. This means you can run background tasks without needing rabbitmq processes or so. Handy!

Some security measures:

• Django listens on 127.0.0.1 on a random port. So it doesn't connect to any external network interfaces.
• Django still validates requests (csrf, ALLOWED_HOSTS).
• Electron page stays unpriviliged: no node, no filesystem access.

Packaging was a bit tricky. There's quite a lot: electron+Chromium, standalone Python, Python dependencies via uv, Django apps + assets. They build the package in CI. Writable data lives outside the app bundle. DMG for mac, windows installer for windows, tgz for linux.

He demoed it. Worked fine. Even with a live "check for upgrades" that installed a new version.

When you think about making a desktop app from your Django website, many things like templates models and static files stay the same. Authentication changes, of course. You need desktop-specific settings. Ensure writeable paths for logs, media files, etc.

Electron is not the only toolkit you can use. Tauri is an alternative that looks nicer (he discovered it too late). For a simpler Python-first desktop wrapper: look at pywebview/positron. If mobile is required, a mobile web or even native toolkit is the best. If you need native widgets, look at QT/PySide, Kivy, BeeWare/Toga.

Note: there was a similar talk in 2015 in Cardiff: https://reinout.vanrees.org/weblog/2015/06/02/09-django-desktop.html

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. Sunset over the Mosel valley, seen from the "Mont Royal" fortifications build by the French king Louis XIV.

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

He works for authentik (an "open-core, self-hosted identity provider").

Note: in the talk he'll mix "access control" and "authorization".

In Django, every model gets some basic permissions for CRUD named after the app and the model. You can ask a user object if it has a certain permission. That method, behind the scenes, will ask all authentication backends with backend.has_perm(self, perm, obj). The default will check whether the user has the permission or if the user belongs to a group that has the permission. So that's quite a query. The backends are queried in turn. If a backend doesn't know if a user has a permission, it can just return None, the next backend will then be checked. If the backend knows the user has no access, it raises PermissionDenied.

The backends have methods like .has_perm(self, perm, obj), but "obj" isn't normally called, it is None by default. But you can implement it if you want object permissions. Django-guardian is an implementation of object permissions for Django by providing an extra authentication backend: ObjectPermissionBackend.

user.has_perm("change_book") asks if the user has the permission to change all books. user.has_perm("change_book", obj=my_book) asks for a specific book.

Generic permission mechanisms deal with user, group, permission. Object permissions add userobjectpermission and groupobjectpermission. Well, that's still reasonably OK.

But then Enterprise comes along with even more wishes:

• Just-in-time privileged access.
• Delegating permissions. Someone has a permission through my permissions. If I lose them, they lose them.
• Custom permissions.
• Group hierarchy.
• Permission inheritance through group hierarchy.

Especially the group hierarchy was a problem. One time, an enterprise they worked with had a group that, after a couple of more groups, was a member of itself... And: django-guardian used Django's group concept, which they couldn't adjust.

So they started modifying django-guardian to use a custom Group model. They also made some other changes by emphasising a new Role concept and using Role to tie users/groups to permissions:

• User can be in a group.
• Groups can be nested.
• A user (directly) or group can have a role.
• A RoleObjectPermission references a role and a permission.
• Lastly they added RoleModelPermission, replacing django's model permission mechanism.

The core SQL query is only 52 lines, so that's not bad. Even with 10k roles and 10k users, the query was below 1ms.

The fork is here: https://github.com/goauthentik/authentik/tree/main/packages/ak-guardian

His slides: https://github.com/gergosimonyi/djangocon-eu-2026/

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. The "Oberburg" castle ruin in Manderscheid.

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

archived = models.GeneratedField(
    output_field=models.BooleanField,
    db_persist=True,
    expression=(models.Q(soft_delete=True | models.Q(....)),
)

Django VPS deployments made simple - Jan Raasch

Let's talk about Django's deployment story.

He demoed deploying a simple Django app to a small virtual server. With python manage.py deploy --serveral-options.

He used django-simple-deploy and a custom plugin for django-simple-deploy that used 'kamal' to do the actual deploying.

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. Some restored remnants of the Virneburg castle.

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

One of Django's "batteries included" batteries is the admin interface. It is great. With a few lines you get Full CRUD, plus filtering, searching and pagination. But it isn't perfect:

• Want drag/drop ordering?
• Nested inlines?
• An extra button next to "edit" and "delete"?
• Form layout with columns?
• change_list_view and change_form_view are hard to extend.
• Better translation support?

(There are plug-ins for most of the individual issues.)

The admin actually predates most of the rest of Django. It has stagnated even though Django got many new features. The admin is a separate framework within django. Lots of patterns from regular Django views don't apply. You're missing musle memory when working on the admin.

The community knows there's a problem. 30% of new proposed fixes are for the admin. There's discussion about a new UI. And there's issue #70 that proposes a change. The community has also been trying:

• django-admin2. Abandoned at the moment.
• Grapelli/Jet. Mostly better skins and extensions on top of the regular admin.
• Wagtail. It is actually a CMS, but people are using its admin interface for Django itself.
• drf-schema-adapter. Her own attempt via django restframework and a frontend app.

What do we want?

• Extendable.
• Composable.
• Django native.
• Pluggable.

So: what if your admin was just regular Django code? Build it on django's generic views: one way to do CRUD, not two. Everything is composable with views, permissions and actions. Plugins will be first-class, not an afterthought. And: you get familiar patterns, your regular Django muscle memory applies.

• Django's class based views as the basis. ListView, CreateView, UpdateView, DeleteView.
• UI layer for breadcrumbs, column headers, dashboard, sidebar.
• Permissions and actions layer.
• Plugin system. She used djp/pluggy.
• A bit of glue: view factories (idea taken from django-admin2). The factory composes the admin page for you.

The project is here: django admin deux.

The current admin.py syntax still works, apart from a change in the import statements. But it has extras like a layout attribute on admin objects that you can use to adjust the page.

The admin generates its own documentation. Especially when you use many plugins, the generated documentation is great for figuring out what is happening and which part of the mechanism is responsible for what.

You can try it without risk, admin-deux and the regular admin can run side-by-side. Within nine months the core of the admin and the most important plugins can be finished and made completely robust. And within two years it could be in widespread use and integrated in the community. (There's a need for funding).

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. Windsborn crater lake near Bettenfeld. One of the very few vulcano craters filled with water north of the Alps. Beautiful in its autumn colors.

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

Full title: advanced ORM kung-fu for on-demand filtering, sorting, and summing 40 million financial transactions.

He's working on a property management platform (so: buildings, rent payments, extra costs, maintenance, grouping per housing complex, etc). 300000 users. 472000 financial accounts. 40 million transactions.

Users expect real-time filtering, sorting and summing. But originally his website often had "please wait for 10 seconds" spinners. This should be improved.

A colleague told him that the database ought to be able to handle everything just fine. So the goal was to fully leverage postgresql through Django's ORM without writing raw SQL.

Some things he discovered:

• Annotations are composable. Almost functional programming.
• Func(template=...) to drop custom SQL expressions into the ORM. You can use them to group items in a custom way, for instance.
• In JSONB, you can use __0 to grab the first element of a list. Use that before using raw SQL.
• Materialized views (note: use "managed=False") means you have pre-computed data available, usable just like a model. You do have to handle those views (create, refresh) yourself, though.
• Coalesce is something he mentioned and it looked useful, but I have to check what it actually does. The slides had a bit too much content to see what was happening.

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. View on Virneburg from the town's similarly-named castle.

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

Full title: Django task workers in subinterpreters: single-server Django applications without process overhead.

He was inspired to tinker with subprocessors by Antony Shaw`s pycon talk

You normally use a wsgi runner like gunicorn to run your django app. There's also daphne, uvicorn and hypercorn: those also support asgi. If you have tasks, you might use celery , RQ or django-Q (or django-tasks). Instead of a single gunicorn, you then have a broker, a worker and a web server: all deployed separately.

He's a fan of the fediverse and wanted to run his own server, but he just wanted one program, not three.

You need python 3.14 to actually try some of the stuff he talks about. And you need to have some longer-running tasks in Django.

• Python 3.14 allows you to run multiple python interpreters in one process. You have separate imports, builtins and separate namespaces per interpreter: isolation. There's even IPC (inter process communication) via memory. Objects are copied. Subinterpreters handle the GIL by each having their own.
• Django: preferably 6.0 as you can then use the new Django task framework.

Combining it, you'd use a subinterpreter for the web runner and one or more for the tasks. He hacked a subclass of one of django tasks' to run something off the queue in a subprocessor.

The demo was the as-you-can-clearly-see version where you have 3 seconds to read 40 lines of logs, so I couldn't really tell what was happening. It seemed to work :-)

Important note: there are some Python libraries you might use that cannot deal with subprocessors yet, for instance numpy and pydantic. So check that before you start experimenting. If you use pure python + psycopg? Give it a try now. Watch the ecosystem. Subinterpreters unlock a new form of parallelism for deferred workflows.

Here are some more links: https://github.com/melhin/parimitham/blob/main/slides/links.md

Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. The Mosel river near Bernkastel-Kues, seen from castle Landshut.