Uploaded August 2026 | Updated September 2026, 2 weeks ago
[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 it'll probably just work. But if it uses C, Cython, Rust, or any other native-compiled language, then you'll 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 beeware.org/mobile-wheels. Let's 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 don't 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: creativecommons.org/licenses/by-nc-sa/4.0
[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 it'll probably just work. But if it uses C, Cython, Rust, or any other native-compiled language, then you'll 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 beeware.org/mobile-wheels. Let's 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 don't 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: creativecommons.org/licenses/by-nc-sa/4.0

![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)
![Data wrangling in a modern terminal - Jan Pipek
[EuroPython 2026 - S3B on 2026-07-16]
๐ค *Data wrangling in a modern terminal by Jan Pipek*
๐ https://ep2026.europython.eu/session/data-wrangling-in-a-modern-terminal
๐ Abstract:
Once we constrain ourselves to a rectangle of fixed-width characters (preferably white on a black background), we start to see the world a bit differently. If we want to thoroughly investigate it (a.k.a. perform data analysis), we have to be equipped with appropriate tools - be it techniques, libraries or standalone console-based applications. Letโs see what the terminal has to offer when reading, manipulating, presenting and even plotting numerical data. We might even finish with a live dashboard your audience will love (or perhaps will not).
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ Data wrangling in a modern terminal - Jan Pipek](https://i.ytimg.com/vi/tx161-RrH8c/mqdefault.jpg)