Discover how PEP 810's explicit lazy imports can dramatically improve Python application startup times. Using a real CLI tool as a case study, that we totally use in our real business, this talk demonstrates practical techniques to optimize import performance while maintaining code clarity and safety.
Python’s Global Interpreter Lock has shaped the way developers build concurrent applications for nearly three decades. While the GIL simplified the CPython ecosystem, it also imposed well-known limits on CPU-bound work and multithreaded scalability. With the introduction of free-threaded Python (3.14t), that is about to change.
This talk explores the history and purpose of the GIL, why it existed for so long, and the innovations that finally made its removal viable. We’ll look at how free-threading affects real workloads through concrete benchmarks. We'll investigate the often overlooked effect of freethreading on webservers. You’ll see how modern servers like Granian, ASGI frameworks, and WSGI stacks behave when threads are no longer serialized by the interpreter.
By the end, you’ll understand not only what the GIL is, but what its disappearance means for scaling Python applications in production. Whether you're building high-throughput APIs, tuning async code, or planning future architecture, free-threaded Python opens the door to new performance ceilings - along with new tradeoffs every developer should know.
Apache Airflow is the most popular Data Workflow Orchestrator - developed under the Apache Software Foundation umbrella. We have 120+ Python distributions in our rep, and we often release ~ 100 of them every two week.
All those distributions are built from a single monorepo.
[jarekpotiuk:~/code/airflow] find . -name 'pyproject.toml' | wc
120 120 4248
This had always posed a lot of challenges and we had a lot of tooling to make it possible, however with the recent development of Python Packaging tools, multipel Packaging PEPs implemented, and with new wave of tools such as uv and prek, our setup is finally manageable and we removed 1000s of line of custom code we wrote before after we applied uv workspaces, switched to prek, started using inline script metadata.
It's a breeze to have monorepo now. This talk explains how.
Bonus content. If you know the differences between dynamically and statically linked libraries in C and other languages, or used NPM - you might recognise the need of being able to use different versions of the same library in the same system. It's not possible in Python. Or is it?
We've figured out a way to eat cake and have it too - and we have "statically linked" libraries in Python. How did we do it?
You will find out how from the talk.
Remember when we said "Infrastructure as Code"? Somehow, the industry heard "Infrastructure as YAML" and ran with it. Now we're drowning in a sea of indentation-sensitive, template-riddled, Jinja2-abused configuration files that make even the most battle-hardened sysadmins weep into their mechanical keyboards.
Enter PyInfra—where your infrastructure is actually code. Real Python. With loops that don’t require learning a DSL. With functions that are... wait for it... actual functions. With error handling that doesn’t involve praying to the YAML gods and sacrificing a virgin bracket.
In this talk, you’ll see how to:
- Write infrastructure automation that your IDE actually understands
- Debug with real stack traces instead of "ERROR: The task includes an option with an undefined variable"
- Use actual Python conditionals instead of when: ansible_os_family == "Debian" and not (ansible_distribution == "Ubuntu" and ansible_distribution_version is version('20.04', '>='))
- Import and reuse code like a civilized developer, not copy-paste playbooks like it’s 1999
- Test your infrastructure code with pytest, not "let’s run it in staging and see what breaks"
We’ll explore how a typical Ansible playbook can be transformed into clean, maintainable Python with PyInfra, shrinking from 500 lines of YAML to 50 lines of readable code. You’ll discover the joy of list comprehensions over with_items, and the power of deployment logic that can actually think.
Stop treating your infrastructure like a configuration file. It’s 2026—your servers deserve better than YAML. They deserve Python.
Warning: This talk may cause uncontrollable urges to refactor all your Ansible playbooks. Side effects include increased productivity, better sleep, and colleagues actually understanding your infrastructure code.
Summary:
ETL stands for "extract, transform, load" and is a synonym for moving data around. This has traditionally often required managing complex systems in the cloud or large data centers. The talk will demonstrate how all this can be greatly simplified by applying modern tools for the task: Python and DuckDB, both open source and readily available to run on most systems - even your notebook.
Description:
ETL stands for "extract, transform, load" and is a synonym for moving data from one system to another.
Traditionally, ETL was done in exactly that order: first you extract the data you want to process, then you transform it and then you load it into the target system. More modern approaches based on data lakes, swap the T and L, since transformation is more efficiently done in a database system, especially when it comes to large volumes of data.
In order to make all this work, the usual approach is to have a workflow system, taking care of managing all the intermediate steps, a large data lake database and distributed storage systems. This results in lots of complexity, need for system/cluster administration and maintenance.
Now, with today's computers, most data sizes used in ETL no longer need all this complexity. Even notebooks or single VMs can handle the load, when used with external object storage, so all you really just need is the right software stack to manage your ETL - without all the overhead:
Python has grown to be the number one programming language on the planet and is especially well suited for integration work due to its many readily available connectors to plenty of backend systems. It often comes preinstalled on Linux machines and is easy to install on most other systems.
DuckDB has emerged as one of the most capable embedded OLAP database systems and supports data lakes with the DuckLake extension, right out of the box. Installation is just a uv add duckdb away.
Both can be run on the same machine and are very resource friendly.
The talk will give an overview of the typical steps involved in ETL processes, give a short intro to DuckDB and showcase how DuckDB can be put to good use when implementing ETL processes. If time permits, I can also cover a few advanced topics addressing optimization strategies.
Resources: - Python.org - DuckDB – An in-process SQL OLAP database management system
Django's built-in admin is powerful, but it's essentially a separate framework within Django and it's 20 years old.
Wouldn't it be nice to be able to work with an admin interface that works like the rest of Django, built on generic CBVs, plugins, and view factories? Django-Admin2, was an attempt at doing just that and it was a fairly successful ptoject.
10 years later, after looking at reviving that project, I realized we needed a fresh approach: Meet Django-Admin-Deux: a proof-of-concept Django admin replacement where CRUD operations are just actions, knowledge transfers both ways, and everything feels like Django.
Let's have a look at what python features and architecture makes this possible
The French digital agency (DINUM) has undertaken to develop an open-source collaborative digital workplace to make the work of public servants simpler and more effective.
This collaborative digital workplace is distributed under an open-source license to allow anyone who wishes to take its applications and integrate them into their preferred tools.
By participating in existing open-source communities, the digital workplace enables the emergence of digital commons that facilitate independence for those who wish to deploy and use them.
Designed with a modular approach, it can be partially or progressively adopted or complement an existing offer.
I propose to present two applications, both technically and functionally, that are integrated into this collaborative suite:
Collaborative editing and documentation: The Suite Docs, based on Prosemirror and Blocknotejs. Developed jointly with Germany and the Netherlands.
File sharing: Drive
These applications share the same technical stack, which relies on Python and the Django framework, Django Rest Framework, and PostgreSQL.
Beyond a list of libraries used, I will present the quality processes we have implemented, the complete workflow from the idea of a new feature to its implementation and deployment. I will share our dev handbook (also under an open-source license) that compiles our best practices.
How what could be qualified as a "Boring Stack" (meaning proven and battle-tested) allows us to focus on solving complex problems.
After the success of last year's impromptu lightning talks session, we will have an official one in the Python Devroom for 2026.
Please submit your talks using this form: - (the link will be made available on Saturday, Jan 31, 2026)
Note: All presentations in this slot will be recorded and made available under a CC-BY license.
Thank you, Python Devroom Organizers