Uploaded August 2026 | Updated September 2026, 2 weeks ago
[EuroPython 2026 - S1 on 2026-07-17]
🎤 *Speeding Up Python with Free Threading and Mypyc by Jukka Lehtosalo*
🔗 https://ep2026.europython.eu/session/speeding-up-python-with-free-threading-and-mypyc
📝 Abstract:
It’s common to hear complaints about Python being slow. In this talk, I will show how to make _some_ Python programs dramatically faster by using Python 3.14’s free threading and ahead-of-time compilation to C extensions using the mypyc compiler, while staying entirely in Python (and CPython).
Free threading can deliver large speedups for CPU-bound code that can be adapted for parallel execution, while mypyc speeds up workloads that benefit from reduced interpreter overhead and that can use static typing. If each can give a 10x speedup in an ideal use case, can we get a “holy grail” 100x speedup by using both?
I’ll introduce several small examples inspired by real-world workloads, measuring and explaining what happens when you apply free threading, mypyc, or both. In practice, relatively few programs are perfect fits for both techniques at once, but when they are, you can get substantial gains. Having both tools available gives you options for attacking a wide range of performance problems.
Along the way, I’ll cover various bottlenecks you are likely to encounter while optimizing real-world workloads. These often limit performance scaling. I'll explain how to diagnose and improve allocation-heavy code and thread contention caused by reference counting, in particular.
---
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 - S1 on 2026-07-17]
🎤 *Speeding Up Python with Free Threading and Mypyc by Jukka Lehtosalo*
🔗 https://ep2026.europython.eu/session/speeding-up-python-with-free-threading-and-mypyc
📝 Abstract:
It’s common to hear complaints about Python being slow. In this talk, I will show how to make _some_ Python programs dramatically faster by using Python 3.14’s free threading and ahead-of-time compilation to C extensions using the mypyc compiler, while staying entirely in Python (and CPython).
Free threading can deliver large speedups for CPU-bound code that can be adapted for parallel execution, while mypyc speeds up workloads that benefit from reduced interpreter overhead and that can use static typing. If each can give a 10x speedup in an ideal use case, can we get a “holy grail” 100x speedup by using both?
I’ll introduce several small examples inspired by real-world workloads, measuring and explaining what happens when you apply free threading, mypyc, or both. In practice, relatively few programs are perfect fits for both techniques at once, but when they are, you can get substantial gains. Having both tools available gives you options for attacking a wide range of performance problems.
Along the way, I’ll cover various bottlenecks you are likely to encounter while optimizing real-world workloads. These often limit performance scaling. I'll explain how to diagnose and improve allocation-heavy code and thread contention caused by reference counting, in particular.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
![Supporting Android and iOS in your Python package - Malcolm Smith
[EuroPython 2026 - S3A on 2026-07-17]
🎤 *Supporting Android and iOS in your Python package by Malcolm Smith*
🔗 https://ep2026.europython.eu/session/supporting-android-and-ios-in-your-python-package
📝 Abstract:
One of the most exciting recent developments in Python is the addition of Android and iOS as officially-supported platforms. This allows us to reach far more users on the devices where they spend the most time.
What does this mean for you as a Python package maintainer? If your package is pure-Python, then itll probably just work. But if it uses C, Cython, Rust, or any other native-compiled language, then youll have to take some steps to make it available to these new platforms.
The mobile support status of the most popular packages on PyPI can be seen at https://beeware.org/mobile-wheels. Lets help push those numbers up! Come to this talk to learn about:
- Why mobile platforms are important for the future of Python
- How to build your package for Android and iOS using cibuildwheel
- How to test your mobile builds – even if you dont have Android or iOS hardware
- How to distribute mobile packages to your users
- How to automate all of these things in your CI system
At the sprints, there will also be an opportunity to put this into practice, by getting personal assistance from the BeeWare team in building your package for mobile.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Supporting Android and iOS in your Python package - Malcolm Smith](https://i.ytimg.com/vi/pZ64kXOnID4/mqdefault.jpg)

![Building a Smart Home Device with MicroPython - Michał Karzyński
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *Building a Smart Home Device with MicroPython by Michał Karzyński*
🔗 https://ep2026.europython.eu/session/building-a-smart-home-device-with-micropython
📝 Abstract:
Your smart home is a wireless network of connected devices which all talk to each other by sending messages into a central hub. If you control the hubs messaging queue, you can control and monitor the network and even create your own custom devices that end up visible in services like Apple or Google Home.
In this talk I will show you what it takes to create such a custom device using an affordable ESP32 microcontroller running MicroPython. Well briefly look at the capabilities of the ESP32 family and why it is a good choice for WiFi-enabled projects. Well talk about the tooling that makes development a pleasure, from flashing firmware to interacting with the board using WebREPL, installing lightweight dependencies with mip, testing, logging, and more.
We will also discuss the MQTT protocol, how our custom devices can send and receive messages, how to integrate third-party Zigbee devices, and how to use Home Assistant as a bridge between our MQTT server and Apple or Google Home. Well see how to use the Mosquitto broker and client tools such as paho.mqtt and how Zigbee2MQTT allows remote sensors to join the same messaging layer.
My goal is to give a practical overview of the hardware and software pieces involved: ESP32, MicroPython tooling, MQTT infrastructure, Zigbee integration, and Home Assistant bridging. If you are comfortable with Python and curious about embedded systems, this talk is for you.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Building a Smart Home Device with MicroPython - Michał Karzyński](https://i.ytimg.com/vi/qRfo0rD4cdY/mqdefault.jpg)
![Binary Dependencies: Identifying the Hidden Packages We All Depend On - Vlad-Stefan Harbuz
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *Binary Dependencies: Identifying the Hidden Packages We All Depend On by Vlad-Stefan Harbuz*
🔗 https://ep2026.europython.eu/session/binary-dependencies-identifying-the-hidden-packages-we-all-depend-on
📝 Abstract:
Package manifests like *pyproject.toml* record source-level dependencies: _pandas_ depends on _numpys_ code. The story is different for binary dependencies, which exist whenever compiled code, like C code, is called from Python. _numpy_ depends on _OpenBLASs_ binaries, but this dependency relationship is not recorded anywhere. This makes _OpenBLAS_ a _phantom (https://www.endorlabs.com/learn/dependency-resolution-in-python-beware-the-phantom-dependency) binary dependency._
Phantom dependencies are therefore hidden from programmers and researchers, which is bad for at least two reasons.
First, security. If one of your binary dependencies has a vulnerability, this means your project is probably also vulnerable — but you wont reliably find out about this, since your dependency is invisible.
Secondly, sustainability. If we cant keep track of our binary dependencies, we cant keep track of their maintainers either, which means we cant credit and financially support (https://opensourcepledge.com/) them. This can lead to maintainer burnout (https://opensourcepledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-together/) which has already created serious supply chain issues.
Python is not only tremendously popular, but also valued for its ability to easily interface with compiled libraries. According to my research, around 20% of Python packages have binary dependencies.
This means that the problem of phantom binary dependencies is widespread, and puts the public at risk of harm, eg if critical infrastructure like hospitals or transportation is compromised by exploiting the aforementioned weaknesses.
I aim to describe how the problem of phantom binary dependencies can be fixed within the Python ecosystem, and demo some of my preliminary work.
First, binary dependencies must be identified. Tools like _auditwheel (https://github.com/pypa/auditwheel/)_ and _elfdeps (https://github.com/python-wheel-build/elfdeps/)_ are able to identify a projects required dynamic libraries (https://vlad.website/how-binary-dependencies-work/ ). If we create better APIs for these tools, and integrate them with package managers such as _pip_ and _uv,_ we can give developers and researchers visibility into binary dependencies, dispelling the phantom.
Beyond this, standards like PEP 725 (https://peps.python.org/pep-0725/) , PEP 770 (https://peps.python.org/pep-0770/) and PEP 804 (https://peps.python.org/pep-0804/) specify how we might record binary dependency relationships in an easily accessible way. Ill explain how we can build on these standards to create tools that will allow users and researchers to explore binary dependencies and identify security issues by default.
Lastly, I want to talk about the road towards the ultimate aim of having binary dependencies be managed not by Python package managers, but by system package managers, as they should be. This will require interoperation between package managers, and Ill explain how this might work.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Binary Dependencies: Identifying the Hidden Packages We All Depend On - Vlad-Stefan Harbuz](https://i.ytimg.com/vi/qooQD1tLVTg/mqdefault.jpg)


![Python Dicts: Past, Present, and Free-Threaded Future - Lysandros Nikolaou
[EuroPython 2026 - S1 on 2026-07-16]
🎤 *Python Dicts: Past, Present, and Free-Threaded Future by Lysandros Nikolaou*
🔗 https://ep2026.europython.eu/session/python-dicts-past-present-and-free-threaded-future
📝 Abstract:
Python dicts are everywhere! They back module namespaces, instance attributes, **kwargs, and of course actual dictionaries. But have you ever wondered how they work under the hood? And more importantly, what happens to them now that free-threaded Python is here?
In this talk, well start by exploring the internals of CPythons dict implementation: how hashing works, the compact table layout that gives you insertion order, and how lookups, insertions, and deletions actually play out in memory. Then well see what had to change for free-threading: how reads remain fast without acquiring locks, what the per-object lock is and when it kicks in, and why making a dict thread-safe is harder than it sounds.
Finally, well look at the ongoing effort to document CPythons thread-safety guarantees for built-in types and what the resulting documentation means for a Python developer writing concurrent code.
The audience will leave with a deep understanding of how Pythons most important data structure works, how its been adapted for a free-threaded world, and what they can (or cant) safely do with dicts across threads.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Python Dicts: Past, Present, and Free-Threaded Future - Lysandros Nikolaou](https://i.ytimg.com/vi/rYbMwGNNFc8/mqdefault.jpg)

![EuroPython 2026 - Conference Opening 🎉
[EuroPython 2026 - S1 on 2026-07-15]
🎤 *Conference Opening 🎉*
🔗 https://ep2026.europython.eu/session/conference-opening
📝 Abstract:
Welcome to EuroPython 2026!
Join us on the opening session, where we will kick-off the conference days, and tell you whats going to happen in the following days.
You will have three days filled with Keynotes, talks, panels, and open spaces, lightning talks, and a weekend full of sprints and other events for people attending the conference.
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 - Conference Opening 🎉](https://i.ytimg.com/vi/srN_3WOqFaQ/mqdefault.jpg)
![Designing and Building Custom Keyboards ⌨️ with Python - Carlos A Aranibar
[EuroPython 2026 - S2 on 2026-07-15]
🎤 *Designing and Building Custom Keyboards ⌨️ with Python by Carlos A Aranibar*
🔗 https://ep2026.europython.eu/session/designing-and-building-custom-keyboards-with-python
📝 Abstract:
Programmers spend countless hours typing, yet we rarely question how keyboard design affects our comfort and productivity. Standard QWERTY layouts and one-size-fits-all hardware often contribute to strain and inefficiency. This talk explores how Python can help you design, build, and optimize your own custom keyboard; from analyzing your typing habits to generating the PCB.
We start with a brief history of keyboard design and the limitations of QWERTY, then introduce alternative layouts (ortholinear, split, and more) and explain why they can reduce strain and improve speed. Next, we use Python to make data-driven decisions: we’ll look at scripts that analyze your codebases or IDE usage to find your most-used characters and symbols, so you can place keys where they matter most for your workflow and favorite languages.
We then move on to PCB design with KidCad and GDSFactory, a Python-based tool for creating keyboard PCBs and exporting Gerber or GDS files for manufacturing. You’ll see how to arrange keys around your hand shape and generate production-ready files. After that, we cover basic assembly and programming your layout with open-source firmware. Finally, we discuss trade-offs: the benefits of a tailored setup (better posture, less finger travel, DIY satisfaction) it can also be a meaningful accessibility solution for users with special needs, limited mobility, or other conditions where standard keyboards become a uncomfortable or unusable. Some of the barriers (cost, time, learning a new layout), plus strategies for gradual adoption and practice tools.
*What you will learn:*
- Why keyboard layout and ergonomics matter for long-term comfort and productivity.
- How to use Python to analyze your typing patterns and inform layout choices.
- How to use KidCad or GDSFactory (Python) to design hardware and generate manufacturing files.
- How to go from design to assembly and firmware, and how to ease the transition to a new layout.
No prior experience with keyboard building or PCB design is required; just curiosity and a desire to create a custom typing experience. By the end, you’ll know how to question your current keyboard and how to start building your own with 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/ Designing and Building Custom Keyboards ⌨️ with Python - Carlos A Aranibar](https://i.ytimg.com/vi/tT_n80RtEtM/mqdefault.jpg)
![Breaking changes – not great, not terrible - Jan Musílek
[EuroPython 2026 - S3A on 2026-07-17]
🎤 *Breaking changes – not great, not terrible by Jan Musílek*
🔗 https://ep2026.europython.eu/session/breaking-changes-not-great-not-terrible
📝 Abstract:
Do you maintain a Python library, REST API or any other user-facing interface? Breaking changes are frowned upon, but from a a certain project size, they become unavoidable.
How do you make the breaking changes manageable? How should you version your package / API? Should you put an upper bound on your dependencies?
Well discuss deprecation, forward and backward compatibility, upgrade strategies and more, illustrated on real-world examples. Our main focus will be on API changes of Python libraries, but the principles are widely applicable.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Breaking changes – not great, not terrible - Jan Musílek](https://i.ytimg.com/vi/tny5Ac4VlIo/mqdefault.jpg)