Uploaded August 2026 | Updated September 2026, 2 weeks ago
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *The Hidden Cost of Complexity: Reducing Cognitive Load in Python by Jarosław Śmietanka*
🔗 https://ep2026.europython.eu/session/the-hidden-cost-of-complexity-reducing-cognitive-load-in-python
📝 Abstract:
Some codebases let you ship a change in minutes. Others turn a one-line fix into weeks of investigation.
The difference is often not skill, tooling, or even architecture—it’s cognitive load.
In this talk, we’ll look at real examples from long-lived Python systems to understand how inheritance, deep nesting, excessive abstraction, microservices, and over-applied DRY silently increase the cost of change.
You’ll learn practical heuristics to recognize high cognitive load early and concrete strategies to reduce it—so your team can move faster without rewriting everything.
This is a pragmatic engineering talk for developers who work in real production code, not greenfield demos.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *The Hidden Cost of Complexity: Reducing Cognitive Load in Python by Jarosław Śmietanka*
🔗 https://ep2026.europython.eu/session/the-hidden-cost-of-complexity-reducing-cognitive-load-in-python
📝 Abstract:
Some codebases let you ship a change in minutes. Others turn a one-line fix into weeks of investigation.
The difference is often not skill, tooling, or even architecture—it’s cognitive load.
In this talk, we’ll look at real examples from long-lived Python systems to understand how inheritance, deep nesting, excessive abstraction, microservices, and over-applied DRY silently increase the cost of change.
You’ll learn practical heuristics to recognize high cognitive load early and concrete strategies to reduce it—so your team can move faster without rewriting everything.
This is a pragmatic engineering talk for developers who work in real production code, not greenfield demos.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
![Friendly Borders: Graph algorithms reveal Eurovision voting patterns - Domagoj Marić
[EuroPython 2026 - S2 on 2026-07-15]
🎤 *Friendly Borders: Graph algorithms reveal Eurovision voting patterns by Domagoj Marić*
🔗 https://ep2026.europython.eu/session/friendly-borders-graph-algorithms-reveal-eurovision-voting-patterns
📝 Abstract:
*Graphs* offer a powerful tool for uncovering relationships and hidden patterns between entities. This presentation provides an introduction to *graph theory,* and demonstrates how graphs are applied across various business domains - from social network analysis and recommendation systems to fraud detection and supply chain optimization. Through an overview of core concepts and algorithmic approaches, the goal is to show how graphs can reveal underlying structures in complex systems.
As a real-world case study, the presentation focuses on *Eurovision voting* - an area long suspected of regional bias and neighbourly favoritism. Using graph-based analysis and community detection techniques, we explore voting patterns between countries to better understand how geography, history, and politics influence the distribution of points. Through visualizations and data-driven insights, the talk demonstrates how graph theory uncovers hidden alliances and behavioral trends within the seemingly light-hearted spectacle of a music contest.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Friendly Borders: Graph algorithms reveal Eurovision voting patterns - Domagoj Marić](https://i.ytimg.com/vi/WcK448FEdR8/mqdefault.jpg)
![Self-Hosted Small Models: From OpenAI Lock-In to Open Models - Filip Makraduli
[EuroPython 2026 - S3B on 2026-07-16]
🎤 *Self-Hosted Small Models: From OpenAI Lock-In to Open Models by Filip Makraduli*
🔗 https://ep2026.europython.eu/session/self-hosted-small-models-from-openai-lock-in-to-open-models
📝 Abstract:
OpenAIs embedding API is the default for most Python RAG applications, but it creates real problems at scale: data privacy (every document leaves your network), cost (per-token pricing compounds fast), no customization (cannot fine-tune or swap models), and no quality validation. Most teams have never measured whether text-embedding-3-large actually works well for their domain.
Open embedding models like BGE-M3, GTE-Qwen2, and E5 now match or beat OpenAI on MTEB benchmarks. The problem is not model quality anymore, it is infrastructure: running these models with proper batching, memory management, and quality assurance.
This talk walks through a practical migration. We start from a typical LangChain app calling OpenAI, switch to self-hosted open models using SIE (an open-source inference server with an OpenAI-compatible endpoint), validate that retrieval quality is maintained using MTEB, and then go beyond what OpenAI offers by adding sparse embeddings for keyword, recall, and cross-encoder reranking for precision.
The talk is aimed at Python developers who currently use OpenAI embeddings and models and want to understand their options. No prior experience with model serving is required.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Self-Hosted Small Models: From OpenAI Lock-In to Open Models - Filip Makraduli](https://i.ytimg.com/vi/WuLZUg-QUmU/mqdefault.jpg)
![Stop firefighting: practical observability for Python APIs, workers & jobs - Daria Korsakova
[EuroPython 2026 - S4 on 2026-07-16]
🎤 *Stop firefighting: practical observability for Python APIs, workers & jobs by Daria Korsakova*
🔗 https://ep2026.europython.eu/session/stop-firefighting-practical-observability-for-python-apis-workers-jobs
📝 Abstract:
Production has a special talent for turning “seems fine” into “why is everything on fire?” — usually because we’re missing signals. A service restarts and never becomes ready, a background worker silently stops consuming tasks, or a database gets overloaded and latency creeps up until downstream services (or customers) notice it first. These situations aren’t unsolvable — they’re preventable with the right signals in place.
I’ve seen how stressful this gets when a system is already in production, but there’s no clear guidance or shared “where to look first” playbook; so every incident starts with guesswork. Over time, we turned those lessons into a lightweight standard that replaces panic mode with a predictable investigation flow.
In this talk, I’ll share a practical, vendor-agnostic observability checklist for a Python setup with three cooperating workloads: an HTTP API, an event-driven worker, and a scheduled daily job. Each workload fails differently, so each requires a different set of signals to stay observable.
We’ll cover what “good enough” looks like for logging, metrics, tracing, and alerting: what to instrument first, what pitfalls to avoid, and how to design alerts that catch problems early without creating noise. You’ll leave with a concrete checklist and a phased rollout order you can apply to your own Python services — without rewriting your system or committing to a specific monitoring vendor.
## *Takeaways*
- A baseline observability checklist every service should have: health/readiness, logging with consistent context, core metrics, and alert routing
- Workload-specific signals: what to watch in APIs vs background workers vs scheduled jobs, and why one size doesn’t fit all
- Structured logging that works in production: a minimal event schema + contextual fields that speed up debugging
- Must-have alerts that prevent silent failures: service never becomes ready, worker stalls, scheduled job misses its run, sustained latency increase
- Where tracing adds value: when it’s worth the effort, what “minimal viable tracing” looks like, and what’s optional at the beginning
- A rollout sequence you can apply incrementally: what to do first, what to add later
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Stop firefighting: practical observability for Python APIs, workers & jobs - Daria Korsakova](https://i.ytimg.com/vi/X7jbc8EVs-w/mqdefault.jpg)

![The Problem with None: Sentinel Values and the Semantics of Absence - Florian Wilhelm
[EuroPython 2026 - S3B on 2026-07-17]
🎤 *The Problem with None: Sentinel Values and the Semantics of Absence by Florian Wilhelm*
🔗 https://ep2026.europython.eu/session/the-problem-with-none-sentinel-values-and-the-semantics-of-absence
📝 Abstract:
None is probably the most overloaded value in Python — and often the wrong one.
Python quietly depends on sentinel values: None, NotImplemented, Ellipsis, dataclasses.MISSING. They aren’t just placeholders. They define semantics, coordinate object interactions, and influence API design in subtle but powerful ways.
In this talk, we treat sentinel values as a deliberate design tool. We’ll uncover how NotImplemented enables double dispatch, why None frequently conflates “missing” with “empty,” and how sentinel patterns permeate the standard library.
But the real tension appears in typing. Python’s type system still cannot properly express sentinel semantics. Optional, overload, and Literal only approximate the problem, and building a fully typed custom sentinel remains an open challenge.
We’ll examine the deferred PEP 661, what it tried to solve, and what its absence means today. Expect practical patterns, real-world examples, and a sharper way to think about absence in Python.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ The Problem with None: Sentinel Values and the Semantics of Absence - Florian Wilhelm](https://i.ytimg.com/vi/XPghRxR7pxk/mqdefault.jpg)
![EuroPython 2026 - CPython Panel
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *EuroPython 2026 CPython Panel*
🔗 https://ep2026.europython.eu/session/cpython-panel
📝 Abstract:
CPython is changing quickly, with major work happening across performance, the JIT, subinterpreters, free-threading, typing, documentation, tooling, and the contributor workflow.
This panel brings together core developers with both long-term experience and newer perspectives to discuss where CPython is heading, why these changes matter, and how new ideas become part of the project.
The conversation will also focus on how people can contribute, whether by testing new features, reporting bugs, fixing issues, improving documentation, reviewing changes, or proposing their own ideas.
The goal is to help attendees understand how CPython works today, where it is going next, and where they can get involved.
* Hosts: Diego Russo
* Panelists:
* Alex Waygood
* Eric Snow
* Ken Jin
* Peter Bierma
* Yuri Selivanov
* Mark Shannon
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ EuroPython 2026 - CPython Panel](https://i.ytimg.com/vi/XSLFcr83ek4/mqdefault.jpg)
![What is this footgun called unittest.mock, and how to avoid misusing it - Claudiu Belu
[EuroPython 2026 - S3B on 2026-07-16]
🎤 *What is this footgun called unittest.mock, and how to avoid misusing it by Claudiu Belu*
🔗 https://ep2026.europython.eu/session/what-is-this-footgun-called-unittest-mock-and-how-to-avoid-misusing-it
📝 Abstract:
Has this ever happened to you? Youre happily coding a new feature in your Python project, and at some point, you make a hasty call:
self._thing.do_someting(rnicro_meters=10)
Youve written unit tests for it, including an assertion line:
mock_do_someting.assret_called_once_with(rnicro_meters=10)
The tests pass, the CI is green, the PR is reviewed and merged. But some time later, the service crashes because the real method does not have the `rnicro_meters` keyword argument in the first place. What happened? And more importantly, did you notice any of the mistakes above? This is a problem weve faced more than a few times over the past few years, and thats a few too many.
Unit tests are crucial in any sort of Python development, from small libraries to large distributed systems. `unittest.mock` is used to isolate dependencies and mock external calls in order to keep the tests simple and focused. But mistakes can slip by (e.g.: attribute typos, wrong keyword arguments, wrong patch locations), just like the three mistakes above, leading to false positive tests and a false sense of confidence in our code quality. This can happen because `Mock` and `MagicMock` silently auto-creates attributes on the fly, even when those attributes do not exist on the real object. These issues become even more pronounced as dependencies change and projects evolve.
In this session, we’ll look at why these false positives happen, and how to avoid them. Topics include:
- Understand how `Mock` and `MagicMock` allow invalid attributes and calls.
- Common pitfalls and anti-patterns with `Mock`, `MagicMock`, and `patch`.
- Using `spec`, `spec_set`, and `autospec` to force mocks to match real objects.
- Ensuring patched functions and methods have their signatures validated.
- How to avoid patching the wrong import path.
- Introducing guardrails in existing projects (e.g. OpenStack’s approach) without rewriting the entire test suite.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ What is this footgun called unittest.mock, and how to avoid misusing it - Claudiu Belu](https://i.ytimg.com/vi/Xcg38WPtqgo/mqdefault.jpg)
![Learning from the not-so-secret Python security cabal - Seth Michael Larson
[EuroPython 2026 - S1 on 2026-07-16]
🎤 *Learning from the not-so-secret Python security cabal by Seth Michael Larson*
🔗 https://ep2026.europython.eu/session/learning-from-the-not-so-secret-python-security-cabal
📝 Abstract:
The CPython runtime is some of the most-used software in the world. Part of maintaining a secure software project like CPython is participating in coordinated vulnerability disclosure (CVD). This process allows security researchers and maintainers of projects to work together to fix vulnerabilities and alert the public, keeping all Python programmers and users safe.
In this talk attendees will learn about how the Python language organizes its security team, how to balance security and open source contribution in coordinated vulnerability disclosure, and the latest in how open source projects can maintain a sustainable vulnerability disclosure program. Attendees that aren’t currently contributing to open source projects, but have an interest in their dependencies being secure, will learn ways they can contribute meaningfully to the security of open source projects they depend on.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Learning from the not-so-secret Python security cabal - Seth Michael Larson](https://i.ytimg.com/vi/Xmr89QEr720/mqdefault.jpg)
![Plugins in python - how it is done - Grzegorz Bokota
[EuroPython 2026 - S2 on 2026-07-17]
🎤 *Plugins in python - how it is done by Grzegorz Bokota*
🔗 https://ep2026.europython.eu/session/plugins-in-python-how-it-is-done
📝 Abstract:
Have you ever wondered how popular tools like pytest or tox are able to discover and use plugins? In this talk we will learn about entry-points in Python package metadata and how they enable plugin discovery. We will review how some popular projects are using this mechanism to create their plugin systems. After a walkthrough of the basics, we will explore how you can use this to create a plugin mechanism for your own project. We will explore possible hook implementations and their advantages and disadvantages. Finally we will learn how to make plugins discoverable on PyPi.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Plugins in python - how it is done - Grzegorz Bokota](https://i.ytimg.com/vi/Xs2IQ37mWJE/mqdefault.jpg)
![Explaining the 5 types of database and how to choose between them — Tibs
[EuroPython 2025 — Terrace 2B on 2025-07-18]
🎤 *Explaining the 5 types of database and how to choose between them by Tibs*
🔗 https://ep2025.europython.eu/session/explaining-the-5-types-of-database-and-how-to-choose-between-them
📝 Abstract:
What database should you choose? Worse, what _kind_ of database should you choose?
My aim is to give you enough information to make that choice, or at least be aware of what the alternatives are.
Id argue that there are five important database types at the moment, differing in how they regard the shape of their data. Ill give a brief introduction to each, explaining how it works, and discuss why you might want to use that particular type of database, depending on your data and what you want to do with it. Ill show case at least one open source example of each.
Ill cover:
* Relational (PostgreSQL®, SQLite)
* Columnar (ClickHouse®)
* Document (OpenSearch®)
* Key Value (Valkey™️)
* and as an extra, Graph (Neo4J®)
The slides are available at https://github.com/Aiven-Labs/the-5-types-of-database
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Explaining the 5 types of database and how to choose between them — Tibs](https://i.ytimg.com/vi/YZmyumwFWOg/mqdefault.jpg)
