Uploaded August 2026 | Updated September 2026, 2 weeks ago
[EuroPython 2026 - S3B on 2026-07-17]
🎤 *When Python Agents Meet 3D: Automating Blender from Natural Language by David Rousset*
🔗 https://ep2026.europython.eu/session/when-python-agents-meet-3d-automating-blender-from-natural-language
📝 Abstract:
What if AI could help design 3D worlds without taking creative control away from humans?
In this talk, I will present a hosted Blender agent that creates and edits 3D scenes from natural language. The agent runs Blender headlessly inside Docker, communicates with it through a TCP socket protocol, and exposes Python-powered tools for scene creation, object manipulation, materials, screenshots, rendering, and asset import. It is built with the Microsoft Agent Framework and Azure AI Foundry, using Python as the bridge between the LLM, Blender’s scripting API, cloud storage, and the hosted runtime.
More than a technical demo, this talk explores a potential future pipeline for AI-assisted 3D creation: a workflow where artists, game designers, architects, and developers can iteratively generate, inspect, modify, and refine 3D environments while keeping human control at every stage. Instead of replacing creative tools, the agent becomes a programmable collaborator that can accelerate repetitive work, propose variations, and turn high-level intent into editable Blender scenes.
Through live examples, we will discuss what this could mean for the future of video game world-building, virtual production, and 3D architecture: faster prototyping, more accessible scene creation, and new ways to move from idea to interactive environment. Attendees will leave with a practical architecture for building Python agents that operate real creative software, and a grounded view of both the opportunities and current limitations of human-in-the-loop AI for 3D design.
---
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 - S3B on 2026-07-17]
🎤 *When Python Agents Meet 3D: Automating Blender from Natural Language by David Rousset*
🔗 https://ep2026.europython.eu/session/when-python-agents-meet-3d-automating-blender-from-natural-language
📝 Abstract:
What if AI could help design 3D worlds without taking creative control away from humans?
In this talk, I will present a hosted Blender agent that creates and edits 3D scenes from natural language. The agent runs Blender headlessly inside Docker, communicates with it through a TCP socket protocol, and exposes Python-powered tools for scene creation, object manipulation, materials, screenshots, rendering, and asset import. It is built with the Microsoft Agent Framework and Azure AI Foundry, using Python as the bridge between the LLM, Blender’s scripting API, cloud storage, and the hosted runtime.
More than a technical demo, this talk explores a potential future pipeline for AI-assisted 3D creation: a workflow where artists, game designers, architects, and developers can iteratively generate, inspect, modify, and refine 3D environments while keeping human control at every stage. Instead of replacing creative tools, the agent becomes a programmable collaborator that can accelerate repetitive work, propose variations, and turn high-level intent into editable Blender scenes.
Through live examples, we will discuss what this could mean for the future of video game world-building, virtual production, and 3D architecture: faster prototyping, more accessible scene creation, and new ways to move from idea to interactive environment. Attendees will leave with a practical architecture for building Python agents that operate real creative software, and a grounded view of both the opportunities and current limitations of human-in-the-loop AI for 3D design.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0

![DuckLake - Take Python and DuckDB for a swim in your data lake - Marc-André Lemburg
[EuroPython 2026 - S4 on 2026-07-15]
🎤 *DuckLake - Take Python and DuckDB for a swim in your data lake by Marc-André Lemburg*
🔗 https://ep2026.europython.eu/session/ducklake-take-python-and-duckdb-for-a-swim-in-your-data-lake
📝 Abstract:
_Pitch_
With DuckDB and DuckLake, managing and analyzing huge data sets is no longer limited to complex cloud infrastructure setups. You can literally run these tasks on your notebook now and at comparable speeds. This talk will show you how.
_Description_
*DuckDB* is an embedded relational analytics database (OLAP) which can be added to a Python project with a simple `uv add duckdb` or `pip install duckdb`. It is both fast and powerful for processing analytical data warehouse workloads, using the well-known PostgreSQL SQL dialect. Data can be stored in memory and persisted on disk. DuckDB is well integrated with Polars via zero copy Apache Arrow data structures, making it a great choice for complex data science and engineering tasks.
*DuckLake* is a extension which comes with DuckDB to add data lake features, meaning that huge data sets can be managed using Parquet files stored on disk or in an object store such as S3. It uses a novel approach to data lakes in that the management structures are stored in a database (DuckDB), instead of complex file and directory structures, as many other data lake systems do. This provides great advantages for implementing smart features such as snapshots, schema evolution or time travel.
Again, installation of the extension is just a simple `INSTALL ducklake` command away, making this a really easy way to configure your own personal lake house - the ideal combination of a data warehouse with a data lake.
The talk will give a short introduction to the database terminology, explain what is novel about the DuckLake approach and then showcase a typical use case for lake houses: storing historical weather data and making this available for analytics to Python applications.
Both DuckDB and DuckLake are MIT licensed.
_Resources:_
- Python.org: https://www.python.org/
- DuckDB – An in-process SQL OLAP database management system: https://duckdb.org/
- DuckLake is an integrated data lake and catalog format – DuckLake: https://ducklake.select/
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-nc-sa/4.0/ DuckLake - Take Python and DuckDB for a swim in your data lake - Marc-André Lemburg](https://i.ytimg.com/vi/TB2P7pb6uR8/mqdefault.jpg)




![The Hidden Cost of Complexity: Reducing Cognitive Load in Python - Jarosław Śmietanka
[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: https://creativecommons.org/licenses/by-nc-sa/4.0/ The Hidden Cost of Complexity: Reducing Cognitive Load in Python - Jarosław Śmietanka](https://i.ytimg.com/vi/W8yhFsA3s3w/mqdefault.jpg)
![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)
