23 May 2026
Planet Python
EuroPython: Call for Onsite Volunteers: Make EuroPython 2026 Happen
We need volunteers to make EuroPython 2026 happen. And you might be exactly who we&aposre looking for!
Before sharing all the information, here is a personal story from me:
The first time I attended EuroPython in-person was as a volunteer. It was the first year after Covid, and I was nervous about traveling abroad for a conference where I didn&apost know anyone personally; there were only friendly faces from the previous year of volunteering online. When I volunteered online, it was easier. I could stay in my comfort zone. But stepping out of that zone to meet people face-to-face? That changed everything πβ€οΈ
Those online faces became really good friends. Now I want to go for every EuroPython because I will get to meet them again. Volunteering with friends became such fun I didn&apost even notice that I was constantly stepping outside my comfort zone π
So, if you&aposre thinking of volunteering, just do it! You will meet awesome humans and have fun while helping people surrounded by positive vibes π

As a volunteer, you&aposre the face of the conference. Your job is to make sure everyone has a great time. We need volunteers to be welcoming, helpful, and collaborative; making sure everyone (including yourself) is comfortable and happy.
There are lots of different ways to help, depending on your interests and availability:
- Registration Desk: Check in attendees, hand out badges, answer questions
- T-Shirt Handout: Hand out awesome EuroPython merch to attendees
- Room Manager: Keep things running smoothly in talk rooms, ensure speakers are ready
- Session Chair: Introduce speakers, manage transitions, signal time, handle Q&A
- Greeter / Badge Check: Welcome people, check for badges at entry
- Runners: Help with whatever is needed at the moment!
You can sign up for as many or as few slots as you want. Even a couple of hours helps. We&aposd appreciate it if you could do more than one, but no pressure, whatever you can give is valuable.
In the volunteering form, tell us what sounds interesting. Get matched with a role that fits your skills and availability. Show up, help out, and be part of something amazing.
That&aposs it. No experience necessary. You don&apost need to be a Python expert. You just need to care about the community and be willing to help out. Whether that&aposs greeting people at the door, managing the schedule, troubleshooting tech issues, or making sure speakers have what they need - we have a place for you.
What do you get?
- π« Free Ticket if you dedicate 10 hours or more (Tutorials + Conference)
- πVolunteer T-Shirt: Awesome EuroPython merch to keep and show off
- β <3 Forever: Featured on the EuroPython 2026 Team page
Check out this page for all the details, including descriptions of various roles: https://ep2026.europython.eu/volunteering/
And if you have more questions? Just reach out volunteers@europython.eu. We&aposre here to help.
π Sponsor Spotlight
We&aposd like to thank Manychat for sponsoring EuroPython.
Manychat builds AI-powered chat automation for 1M+ creators and brands at real production scale.
π Stay Connected
Follow us on social media and subscribe to our newsletter for all the updates:
π Sign up for the newsletter: https://blog.europython.eu/portal/signup
- LinkedIn: https://www.linkedin.com/company/europython/
- X/Twitter: https://x.com/europython
- Mastodon: https://fosstodon.org/@europython
- Bluesky: https://bsky.app/profile/europython.eu
- Instagram: https://www.instagram.com/europython/
- YouTube: https://www.youtube.com/@EuroPythonConference
Hopefully, we'll see you on this side soon π π
Cheers,
Sangarshanan Veera, EuroPython 2026 Communications Team
Sign up for EuroPython Blog
The official blog of everything & anything EuroPython! EuroPython 2026 13-19 July, KrakΓ³w
No spam. Unsubscribe anytime.
23 May 2026 7:00am GMT
22 May 2026
Planet Python
Kay Hayen: Nuitka Release 4.1
This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler, "download now".
This release adds many new features and corrections with a focus on async code compatibility, missing generics features, and Python 3.14 compatibility and Python compilation scalability yet again.
Bug Fixes
-
Python 3.14: Fix, decorators were breaking when disabling deferred annotations. (Fixed in 4.0.1 already.)
-
Fix, nested loops could have wrong traces lead to mis-optimization. (Fixed in 4.0.1 already.)
-
Plugins: Fix, run-time check of package configuration was incorrect. (Fixed in 4.0.1 already.)
-
Compatibility: Fix,
__builtins__lacked necessary compatibility in compiled functions. (Fixed in 4.0.1 already.) -
Distutils: Fix, incorrect UTF-8 decoding was used for TOML input file parsing. (Fixed in 4.0.1 already.)
-
Fix, multiple hard value assignments could cause compile time crashes. (Fixed in 4.0.1 already.)
-
Fix, string concatenation was not properly annotating exception exits. (Fixed in 4.0.2 already.)
-
Windows: Fix,
--verbose-outputand--show-modules-outputdid not work with forward slashes. (Fixed in 4.0.2 already.) -
Python 3.14: Fix, there were various compatibility issues including dictionary watchers and inline values. (Fixed in 4.0.2 already.)
-
Python 3.14: Fix, stack pointer initialization to
localspluswas incorrect to avoid garbage collection issues. (Fixed in 4.0.2 already.) -
Python 3.12+: Fix, generic type variable scoping in classes was incorrect. (Fixed in 4.0.2 already.)
-
Python 3.12+: Fix, there were various issues with function generics. (Fixed in 4.0.2 already.)
-
Python 3.8+: Fix, names in named expressions were not mangled. (Fixed in 4.0.2 already.)
-
Plugins: Fix, module checksums were not robust against quoting style of module-name entry in YAML configurations. (Fixed in 4.0.2 already.)
-
Plugins: Fix, doing imports in queried expressions caused corruption. (Fixed in 4.0.2 already.)
-
UI: Fix, support for
uv_buildin the--projectoption was broken. (Fixed in 4.0.2 already.) -
Compatibility: Fix, names assigned in assignment expressions were not mangled. (Fixed in 4.0.2 already.)
-
Python 3.12+: Fix, there were still various issues with function generics. (Fixed in 4.0.3 already.)
-
Clang: Fix, debug mode was disabled for clang generally, but only ClangCL and macOS Clang didn't want it. (Fixed in 4.0.3 already.)
-
Zig: Fix,
--windows-console-mode=attach|disablewas not working when using Zig. (Fixed in 4.0.3 already.) -
macOS: Fix, yet another way self dependencies can look like, needed to have support added. (Fixed in 4.0.3 already.)
-
Python 3.12+: Fix, generic types in classes had bugs with multiple type variables. (Fixed in 4.0.3 already.)
-
Scons: Fix, repeated builds were not producing binary identical results. (Fixed in 4.0.3 already.)
-
Scons: Fix, compiling with newer Python versions did not fall back to Zig when the developer prompt MSVC was unusable, and error reporting could crash. (Fixed in 4.0.4 already.)
-
Zig: Fix, the workaround for Windows console mode
attachordisablewas incorrectly applied on non-Windows platforms. (Fixed in 4.0.4 already.) -
Standalone: Fix, linking with Python Build Standalone failed because
libHacl_Hash_SHA2was not filtered out unconditionally. (Fixed in 4.0.4 already.) -
Python 3.6+: Fix, exceptions like
CancelledErrorthrown into an async generator awaiting an inner awaitable could be swallowed, causing crashes. (Fixed in 4.0.4 already.) -
Fix, not all ordered set modules accepted generators for update. (Fixed in 4.0.5 already.)
-
Plugins: Disabled warning about rebuilding the
pytokensextension module. (Fixed in 4.0.5 already.) -
Standalone: Filtered
libHacl_Hash_SHA2from link libs unconditionally. (Fixed in 4.0.5 already.) -
Debugging: Disabled unusable unicode consistency checks for Python versions 3.4 to 3.6. (Fixed in 4.0.5 already.)
-
Python3.12+ Avoided cloning call nodes on class level which caused issues with generic functions in combination with decorators. (Added in 4.0.5 already.)
-
Python 3.12+: Added support for generic type variables in
async deffunctions. (Added in 4.0.5 already.) -
UI: Fix, flushing outputs for prompts was not working in all cases when progress bars were enabled. (Fixed in 4.0.6 already.)
-
UI: Fix, unused variable warnings were missing at C compile time when using
zigas a C compiler. (Fixed in 4.0.6 already.) -
Scons: Fix, forced stdout and stderr paths as a feature was broken. (Fixed in 4.0.6 already.)
-
Fix, replacing a branch did not accurately track shared active variables causing optimization crashes. (Fixed in 4.0.7 already.)
-
macOS: Fix, failed to remove extended attributes because files need to be made writable first. (Fixed in 4.0.7 already.)
-
Fix, dict
popandsetdefaultusing with:=rewrites lacked exception-exit annotations for un-hashable keys. (Fixed in 4.0.8 already.) -
Python 3.13: Fix, the
__parameters__attribute of generic classes was not working. (Fixed in 4.0.8 already.) -
Python 3.11+: Fix, starred arguments were not working as type variables. (Fixed in 4.0.8 already.)
-
Python2: Fix,
FileNotFoundErrorcompatibility fallback handling was not working properly. (Fixed in 4.0.8 already.) -
Compatibility: Fix, loop ownership check in value traces was missing, causing issues with nested loops.
-
Windows: Improved
--windows-console-mode=attachto properly handle console handles, enabling cases likeos.systemto work nicely. -
Python2: Fix, there was a compatibility issue where providing default values to the
mkdtempfunction was failing. -
Windows: Fix, there were spurious issues with C23 embedding in 32-bit MinGW64 by switching to
coff_objresource mode for it as well. -
Plugins: Fix, the
post-import-codeexecution could fail because the triggering sub-package was not yet available insys.modules. -
UI: Fix, listing package DLLs with
--list-package-dllswas broken due to recent plugin lifecycle changes. -
UI: Fix,
--list-package-exewas not working properly on non-Windows platforms failing to detect executable files correctly. -
UI: Handled paths starting with
{PROGRAM_DIR}the same as a relative path when parsing the--onefile-tempdir-specoption. -
Plugins: Followed multiprocessing
forkserverchanges for newer Python versions. -
Python 3.12+: Fix, generic class type parameters handling was incorrect.
-
Python 3.12: Fix, deferred evaluation of type aliases was failing.
-
Python 3.12+: Aligned
sumbuilt-in float summation with CPython's compensated sum for better accuracy. -
Python 3.10+: Fix, uncompiled coroutine
throw()return handling was incorrect, restoring completed coroutine results viaStopIteration.valuerather than exposing them as ordinary return values to the outer await chain. -
Python 3.13+: Fix, uncompiled coroutine
cancel()/awaitsuspension handling was incorrect, improved to ensure integration compatibility. -
macOS: Made finding
create-dmgmore robustly by also checking the Homebrew path for Intel and fromPATHproperly. -
Compatibility: Fix, class frames were not exposing frame locals.
-
UI: Detected
static-libpythonproblems, which affected some forms of Anaconda. -
Distutils: Rejected
--projectmixed with--mainarguments as it is not useful. -
macOS: Fix,
zigfromPATHor fromziglangwas not being used. -
Distutils: Fix, the wrong
module-rootconfig value was being checked foruvbuild backend. -
macOS: Fix, was attempting to change removed (rejected) DLLs, which of course failed and errored out.
-
Python 3.14: Fix, tuple reuse was not fully compatible, potentially causing crashes due to outdated hash caches.
-
Fix, fake modules were still being attempted to located when imported by other code, which could conflict with existing modules.
-
Python 3.5+: Fix, failed to send uncompiled coroutines the sent in value in
yield from. -
Fix, older
gcccompilers lacking newer intrinsic methods had compilation issues that needed to be addressed. -
Standalone: Fix, multiphase module extension modules with post-load code were not working properly.
-
Fix, Avoid using the non-inline copy of
pkg_resourceswith the inline copy of Jinja2. These could mismatch and cause errors. -
Fix, loops could make releasing of previous values very unclear, causing optimization errors.
-
Fix,
incbinresource mode was not working with oldgccC++ fallback. -
Python 3.4 to 3.6: Fix, bytecode demotion was not working properly for these versions, also bytecode only files not working.
-
Plugins: Added a check for the broken
patchelfversions 0.10 and 0.11 to prevent breaking Qt plugins. -
Android: Allowed
patchelfversion 0.18 on Android. -
Windows: Fix, the header path for self uninstalled Python was not detected correctly.
-
Release: Fix, inclusion of the
pkg_resourcesinline copy for Python 2 to source distributions was missing. -
UI: Detected the OBS versions of SUSE Linux better.
-
Suse: Allowed using
patchelf0.18.0 there too. -
Python 3.11: Fix, package and module dicts were not aligned close enough to avoid a CPython bug.
-
Fix, unbound compiled methods could crash when called without an object passed.
-
Standalone: Fix, multiphase module extension modules with postload. (Fixed in 4.0.8 already.)
-
Onefile: Fix, while waiting for the child, it may already be terminated.
-
macOS: Removed existing absolute rpaths for Homebrew and MacPorts.
-
Python 3.14: Avoided warning in CPython headers.
-
Python 3.14: Followed allocator changes more closely.
-
Compatibility: Avoided using
pkg_resourcesfor Jinja2 template location for loading. -
No-GIL: Applied some bug fixes to get basic things to work.
Package Support
-
Standalone: Add support for newer
paddleversion. (Added in 4.0.1 already.) -
Standalone: Add workaround for refcount checks of
pandas. (Fixed in 4.0.1 already.) -
Standalone: Add support for newer
h5pyversion. (Added in 4.0.2 already.) -
Standalone: Add support for newer
scipypackage. (Added in 4.0.2 already.) -
Plugins: Revert accidental
os.getenvoveros.environ.getchanges in anti-bloat configurations that stopped them from working. Affected packages arenetworkx,persistent, andtensorflow. (Fixed in 4.0.5 already.) -
Standalone: Added missing DLLs for
openvino. (Added in 4.0.7 already.) -
Enhanced the package configuration YAML schema by adding the
relative_toparameter forfrom_filenamesDLL specification, avoiding error-prone purely relative paths. -
Standalone: Fix,
flet_desktopapp assets were missing, now preserving the packaged runtime and sidecar DLLs. -
Standalone: Added support for the
tyropackage. -
Standalone: Added data files for the
perfettopackage. -
Standalone: Added support for
anyioprocess forking. -
Standalone: Added support for the
plotly.graphpackage. -
Anaconda: Fix, dependencies for the
numpyconda package on Windows were incorrect. -
Plugins: Enhanced the auto-icon hack in PySide6 to use compatible class names.
-
Standalone: Fix, Qt libraries were duplicated with
PySide6WebEngine framework support on macOS. -
Plugins: Fix, automatic detection of
mypycruntime dependencies was including all top level modules of the containing package by accident. (Fixed in 4.0.5 already.) -
Anaconda: Fix,
delvewheelplugin was not working with Python 3.8+. This enhances compatibility with installed PyPI packages that use it for their DLLs. (Fixed in 4.0.6 already.) -
Plugins: Fix, our protection workaround could confuse methods used with
PySide6.
New Features
-
UI: Added the
--recommended-python-versionoption to display recommended Python versions for supported, working, or commercial usage. -
UI: Add message to inform users about
Nuitka[onefile]if compression is not installed. (Added in 4.0.1 already.) -
UI: Add support for
uv_buildin the--projectoption. (Added in 4.0.1 already.) -
Onefile: Allow extra includes as well. (Added in 4.0.2 already.)
-
UI: Add
nuitka-project-setfeature to define project variables, checking for collisions with reserved runtime variables. (Added in 4.0.2 already.) -
Scons: Added new option to select
--reproduciblebuilds or not. (Added in 4.0.6 already.) -
Python 3.10+: Added support for
importlib.metadata.package_distributions(). (Added in 4.0.8 already.) -
Plugins: Added support for the multiprocessing
forkservercontext. (Added in 4.0.8 already, for 4.1 Python 3.6 and earlier, as well as 3.14 support were added too.) -
Reports: Added structured resource usage (
rusage) performance information to compilation reports. -
Reports: Included individual module-level C compiler caching (
ccache/clcache) statistics in compilation reports. -
Added support for detecting and correctly resolving the Python prefix for the
PyEnv on HomebrewPython flavor. -
macOS: Added support for
rusageinformation for Scons. -
UI: Added the
__compiled__.extension_filenameattribute to give the real filename of the containing extension module. -
Windows: Added support for
--clangor ARM. (Added in 4.0.8 already.) -
Windows: Added support for resources names as not just integers, important when we copy them from template files.
-
MacPorts: Added basic support for this Python flavor. More work will be needed to get it to work fully though.
Optimization
-
Avoid including
importlib._bootstrapandimportlib._bootstrap_external. (Added in 4.0.1 already.) -
Linux: Cached the
syscallused for time keeping during compilation to avoid loadinglibcfor each trace. (Added in 4.0.8 already.) -
UI: Output a warning for modules that remain unfinished after the third optimization pass.
-
Added an extra micro pass trigger when new variables are introduced or variable usage changes severely, ensuring optimizations are fully propagated, avoiding unnecessary extra full passes.
-
Provided scripts to compile Python statically with PGO tailored for Nuitka on Linux, Windows, and macOS.
-
Added support for running the Data Composer tool from a compiled Nuitka binary without spawning an uncompiled Python process.
-
Enhanced the usage of
vectorcallforPyCFunctionobjects by directly checking for its presence instead of relying purely on flags, allowing more frequent use of this faster execution path. -
Cached frequently used declarations for top-level variables to speed up C code generation.
-
Sped up trace collection merging by avoiding unnecessary set creation and using a set instead of a list for escaped traces.
-
Optimized plugin hook execution by tracking overloaded methods and added an option to show plugin usage statistics.
-
Improved performance of module location by avoiding unnecessary module name reconstruction and redundant filesystem checks for pre-loaded packages.
-
Improved the caching of distribution name lookups to effectively avoid repeated IO operations across all package types.
-
Plugins: Cached callback plugin dispatch for
onFunctionBodyParsingandonClassBodyParsingto skip argument computation when no plugin overrides them. -
Python 3.13: Handled sub-packages of
pathlibas hard modules. -
Handled hard attributes through merge traces as well.
-
Made constant blobs more compact by avoiding repeated identifiers and unnecessary fields.
-
Enhanced Python compilation scripts further. (Fixed in 4.0.8 already.)
-
Recognized late incomplete variables better. (Fixed in 4.0.8 already.)
-
Made constant blobs more compact. (Fixed in 4.0.8 already.)
-
Optimized calls with only constant keywords and variable posargs too.
Anti-Bloat
-
Fix, memory bloat occurred when C compiling
sqlalchemy. (Fixed in 4.0.2 already.) -
Avoid using
pydocinPySimpleGUI. (Added in 4.0.2 already.) -
Avoided using
doctestfromzodbpickle. (Added in 4.0.5 already.) -
Avoided inclusion of
cythonwhen usingpyav. (Added in 4.0.7 already.) -
Avoided including
typing_extensionswhen usingnumpy. (Added in 4.0.7 already.)
Organizational
-
UI: Relocated the warning about the available source code of extension modules to be evaluated at a more appropriate time.
-
Debian: Remove recommendation for
libfuse2package as it is no longer useful. -
Debian: Used
platformdirsinstead ofappdirs. -
Debugging: Removed Python 3.11+ restriction for
clang-formatas it is available everywhere, even Python 2.7, and we still want nicely formatted code when we read things. (Added in 4.0.6 already.) -
Removed no longer useful inline copy of
wax_off. We have our own stubs generator project. -
Release: Added missing package to the CI container for building Nuitka Debian packages.
-
Developer: Updated AI instructions for creating Minimal Reproducible Examples (MRE) to skip unneeded C compilation.
-
Debugging: Added an internal function for checking if a string is a valid Python identifier.
-
AI: Added a task in Visual Studio Code to export the currently selected Python interpreter path to a file, making it available as "python" and "pip" matching the selected interpreter. This makes it easier to use a specific version with no instructions needed.
-
AI: Updated the rules to instruct AI to only generate useful comments that add context not present in the code.
-
Containers: Added template rendering support for Jinja2 (
.j2) container files in our internal Podman tools. -
Projects: Clarified the current status and rationale of Python 2.6 support in the developer manual.
-
Debugging: Added experimental flag
--experimental=ignore-extra-micro-passto allow ignoring extra micro pass detection. -
Visual Code: Added integration scripts for
bashandzshautocompletion of Nuitka CLI options. These are now also integrated into Visual Studio Code terminal profiles and the Debian package. -
RPM: Included the Python compile script for Linux.
-
RPM: Removed the requirement for
distutilsin the spec.
Tests
-
Install only necessary build tools for test cases.
-
Avoided spurious failures in reference counting tests due to Python internal caching differences. (Fixed in 4.0.3 already.)
-
Fix, the parsing of the compilation report for reflected tests was incorrect.
-
Python 3.14: Ignored a syntax error message change.
-
Python 3.14: Added test execution support options to the main test runner to use this version as well.
-
Fix, the runner binary path was mishandled for the third pass of reflected compilations.
-
Removed the usage of obsolete plugins in reflected compilation tests.
-
Debugging: Prevented boolean testing of
namedtuplesto avoid unexpected bugs. -
Added the
Testsuffix to syntax test files and disabled "python" mode and spell checking for them to resolve issues reported in IDEs. -
Fix, newline handling in diff outputs from the output comparison tool was incorrect.
-
Covered
post-import-codefunctionality with a new subpackage test case. -
Prevented the program test suite from running an unnecessary variant to save execution time.
-
macOS: Ignored differences from GUI framework error traces in headless runs in output comparisons.
-
Reflected test for Nuitka, where it compiles itself and compares its operation has been restored to functional state.
-
Used the new method to clear internal caches if available for reference counts.
-
Disabled running nested loops test with Python 2.6.
-
Containers: Detected Python 2 defaulting containers in Podman tooling.
Cleanups
-
UI: Fix, there was a double space in the Windows Runtime DLLs inclusion message. (Fixed in 4.0.1 already.)
-
Onefile: Separated files and defines for extra includes for onefile boot and Python build.
-
Scons: Provided nicer errors in case of "unset" variables being used, so we can tell it.
-
Refactored the process execution results to correctly utilize our
namedtuplesvariant, that makes it easier to understand what code does with the results. -
Quality: Enabled automatic conversion of em-dashes and en-dashes in code comments to the autoformat tool. AI won't stop producing them and they can cause
SyntaxErrorfor older Python versions, nor is unnecessarily using UTF-8 welcome. -
Ensured that cloned outline nodes are assigned their correct names immediately upon creation, that avoids inconsistencies during their creation.
-
Quality: Updated to the latest versions of
blackand adopted a fasterisortexecution by caching results. -
Quality: Modified the PyLint wrapper to exit gracefully instead of raising an error when no matching files require checking.
-
Quality: Avoided checking YAML package configuration files twice, since autoformat already handles them.
-
Quality: Ensured that YAML package configuration checks output the original filename instead of the temporary one when a failure occurs.
-
Quality: Prevented pushing of tags from triggering git pre-push quality checks.
-
Quality: Silenced the output of
optipngandjpegoptimduring image optimization auto-formatting. -
Visual Code: Added the generated Python alias path file to the ignore list.
-
Quality: Enabled auto-formatting for the Nuitka devcontainer configuration file.
-
Watch: Avoided absolute paths in compilation to make reports more comparable across machines.
-
Quality: Changed
mdformatchecks to run only once and silently. -
Scons: Disabled format security errors in debug mode and moved Python-related warning disables into common build setup code.
-
Quality: Updated to the latest
deepdiffversion. -
Scons: Avoided MSVC telemetry since it can produce outputs that break CI.
-
Debugging: Enhanced non-deployment handler for importing excluded modules.
-
Split import module finding functionality into more pieces for enhanced readability.
-
Debugging: Added more assertions for constants loading and checking.
-
macOS: Dropped the
universaltarget arch. -
Debugging: Added more traces for deep hash verification.
Summary
This release builds on the scalability improvements established in 4.0, with enhanced Python 3.14 support, expanded package compatibility, and significant optimization work.
The --project option seems usable now.
Python 3.14 support remains experimental, but only barely made the cut, and probably will get there in hotfixes. Some of the corrections came in so late before the release, that it was just not possible to feel good about declaring it fully supported just yet.
22 May 2026 10:00pm GMT
Python Morsels: What types of exceptions should you catch?
The trickiest programming bugs are often caused by catching exceptions that you didn't mean to catch or handling exceptions in ways that **obfuscate the actual error that's occurring. Which exceptions should you catch and which should you leave unhandled?
Catching many exceptions at once
When catching an exception, it's generally considered a good idea to only catch exceptions if you understand their origin.
Here we have some code that catches many exception types at once. We're catching a ValueError, a TypeError, a KeyError, and a NameError exception:
import csv
import datetime
import sys
def parse_date(date_string):
return datetime.date.fromisoformat(date_string)
[filename] = sys.argv[1:]
with open(filename) as csv_file:
reader = csv.DictReader(csv_file)
for n, row in enumerate(reader, start=1):
name = row["name"]
try:
start, end = parse_date(row["start"]), parse_date(row["end"])
except (ValueError, TypeError, KeyError, NameError) as e:
error = type(e).__name__
print(f"{error}: Invalid date on line {n}", file=sys.stderr)
continue
time = end - start
print(f"{name}: {time.days} days")
It's not entirely clear why it catches each of these types of exceptions.
When will a NameError be raised?
We probably shouldn't be catching β¦
Read the full article: https://www.pythonmorsels.com/what-types-of-exceptions-should-you-catch/
22 May 2026 5:45pm GMT
Django community aggregator: Community blog posts
Issue 338: Django 6.1 alpha 1 released
News
Django 6.1 alpha 1 released
Django 6.1 alpha 1 has been released, signaling the next round of framework updates headed your way. Plan a quick test run in a staging environment so you can catch compatibility issues early as 6.1 develops.
Wagtail CMS News
Wagtail accessibility statistics for GAAD 2026
Wagtail accessibility statistics for GAAD 2026 give a focused look at how well your CMS setup supports real accessibility needs. Use the figures to spot gaps and prioritize the most impactful improvements.
Updates to Django
Today, "Updates to Django" is presented by Pradhvan from Djangonaut Space! π
Last week we had 16 pull requests merged into Django by 11 different contributors - including 2 first-time contributors!
Congratulations to somi and Kasey for having their first commits merged into Django - welcome on board! π₯³
This week's Django highlights: π¦
- Deprecated
QuerySet.select_related()with no arguments, along with the corresponding admin options that relied on this implicit form. (#36593)
RedirectViewnow supports apreserve_requestattribute, letting redirects keep the original HTTP method and body by returning 307 or 308 instead of 302 or 301. (#37062)
- Admin actions are now also shown on the object edit page, allowing bulk actions to be triggered directly from the change form. (#12090)
- Fixed Oracle compound-query compilation by clearing unnecessary ordering from combined query components in unions and
ORDER BYwrappers. (#36938)
That's all for this week in Django development! ππ¦
Sponsored Link
Middleware, but for AI agents
Django middleware composes request handlers. Harnesses do the same for AI agents - Claude Code, Codex, Gemini in one coordinated system. Learn what a harness actually is, why it's a new primitive, and how to engineer one that holds in production. Apache 2.0, open source.

Articles
My experience at PyCon US 2026
A first-person look at PyCon US 2026 with takeaways for developers who care about Python and the community around it. Expect practical impressions from talks and the conference vibe, not a generic recap.
PyCon US 2026 Recap
Will Vincent from PyCharm (and this newsletter!) shares seven days of talks, sprints, and hallway track conversations from this year's event.
My First PyConUS Experience
Jon Gould from Foxley Talent relates his first experience, takeaways, and comparisons to DjangoCons.
PostgreSQL 19 Beta: The Four Features You'll Actually Feel
PostgreSQL 19 Beta brings four changes highlighted for real-world impact, with a focus on what developers will actually notice. Expect a practical walkthrough rather than a long list of release notes.
Core Dispatch #4
Core Dispatch recaps a packed few weeks in the Python core world, including the arrival of Python 3.15 beta 1, free-threading improvements, PEP 788 landing in CPython, and a wave of new core developer activity.
Anything that could go wrong, will. The excuse is optional.
A thoughtful take on Murphy's Law in software engineering: resilient teams don't avoid risk or ignore it, they design systems assuming failure will happen and plan accordingly.
My PyCon US 2026
A chronological recap of PyCon US 2026 in Long Beach, with live notes ranging from the first AI track talk on AI-assisted contributions and maintainer load to security updates, community building, and Djangonaut Space. Expect practical takeaways about how AI affects review and conflict in open source, plus plenty of Django community moments including "Django on the Med."
Events
Organizing DjangoCon Europe 2026: The Afterthoughts | Blog with LOGIC
Find practical after-the-fact takeaways from organizing DjangoCon Europe 2026, focused on the details people usually only notice after the event. A useful read for anyone planning Django community events or sharpening their conference workflow.
Videos
Tech Hiring has got a FRAUD problem!
Tech hiring can attract fraud, from fake postings to misleading recruiting signals. Keep an eye on red flags in job listings and interview processes so you can spot scams early and protect candidates.
Podcasts
Django Chat #204:How France Ditched Microsoft with Samuel Paccoud
France's shift away from Microsoft is tied to decisions and experiences Samuel Paccoud discusses. The focus is on what prompted the move and what it meant operationally for organizations involved.
Django Job Board
Founding Engineer at MyDataValue
Junior Software Developer (Apprentice) at UCS Assist
PyPI Sustainability Engineer at Python Software Foundation
Projects
mliezun/caddy-snake
Caddy plugin to serve Python apps
AvaCodeSolutions/django-email-learning
An open source Django app for creating email-based learning platforms with IMAP integration and React frontend components.
ehmatthes/gh-profiler
Examine a GitHub user's profile, to help quickly decide how much to invest in their contributions. Was discussed by many maintainers at PyCon US sprints.
22 May 2026 2:00pm GMT
Planet Twisted
Glyph Lefkowitz: Opaque Types in Python
Let's say you're writing a Python library.
In this library, you have some collection of state that represents "options" or "configuration" for a bunch of operations. Such a set of options is a bundle of potentially ever-increasing complexity. Thus, you will want it to have an extremely minimal compatibility surface, with a very carefully chosen public interface, that is either small, or perhaps nothing at all. Such an object conveys state and might have some private behavior, but all you want consumers to be able to do is build it in very constrained, specific ways, and then pass it along as a parameter to your own APIs.
By way of example, imagine that you're wrapping a library that handles shipping physical packages.
There are a zillion ways to do it ship a package. There are different carriers who can ship it for you. There's air freight, and ground freight, and sea freight. There's overnight shipping. There's the option to require a signature. There's package tracking and certified mail. Suffice it to say, lots of stuff.
If you are starting out to implement such a library, you might need an object called something like ShippingOptions that encapsulates some of this. At the core of your library you might have a function like this:
1 2 3 4 5 |
|
If you are starting out implementing such a library, you know that you're going to get the initial implementation of ShippingOptions wrong; or, at the very least, if not "wrong", then "incomplete". You should not want to commit to an expansive public API with a ton of different attributes until you really understand the problem domain pretty well.
Yet, ShippingOptions is absolutely vital to the rest of your library. You'll need to construct it and pass it to various methods like estimateShippingCost and shipPackage. So you're not going to want a ton of complexity and churn as you evolve it to be more complex.
Worse yet, this object has to hold a ton of state. It's got attributes, maybe even quite complex internal attributes that relate to different shipping services.
Right now, today, you need to add something so you can have "no rush", "standard" and "expedited" options. You can't just put off implementing that indefinitely until you can come up with the perfect shape. What to do?
The tool you want here is the opaque data type design pattern. C is lousy with such things (FILE, pthread_*_t, fd_set, etc). A typedef in a header file can easily achieve this.
But in Python, if you expose a dataclass - or any class, really - even if you keep all your fields private, the constructor is still, inherently, public. You can make it raise an exception or something, but your type checker still won't help your users; it'll still look like it's a normal class.
Luckily, Python typing provides a tool for this: typing.NewType.
Let's review our requirements:
- We need a type that our client code can use in its type annotations; it needs to be public.
- They need to be able to consruct it somehow, even if they shouldn't be able to see its attributes or its internal constructor arguments.
- To express high-level things (like "ship fast") that should stay supported as we add more nuanced and complex configurations in the future (like "ship with the fastest possible option provided by the lowest-cost carrier that supports signature verification").
In order to solve these problems respectively, we will use:
- a public
NewType, which gives us our public name... - which wraps a private class with entirely private attributes, to give us an actual data structure, while not exposing the constructor,
- a set of public constructor functions, which returns our
NewType.
When we put that all together, it looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
As a snapshot in time, this is not all that interesting; we could have just exposed _RealShipOpts as a public class and saved ourselves some time. The fact that this exposes a constructor that takes a string is not a big deal for the present moment. For an initial quick and dirty implementation, we can just do checks like if options._speed == "fast" in our shipping and estimation code.
However, the main thing we are doing here is preserving our flexibility to evolve the related APIs into the future, so let's see how we might do that. For example, let's allow the shipping options to contain a concrete and specific carrier and freight method:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
As a NewType, our public ShippingOptions type doesn't have a constructor. Since _RealShipOpts is private, and all its attributes are private, we can completely remove the old versions.
Anything within our shipping library can still access the private variables on ShippingOptions; as a NewType, it's the same type as its base at runtime, so it presents minimal1 overhead.
Clients outside our shipping library can still call all of our public constructors: shipFast, shipNormal, and shipSlow all still work with the same (as far as calling code knows) signature and behavior.
If you need to build and convey some state within your public API, while avoiding breakages associated with compatibility churn, hopefully this technique can help you do that!
Acknowledgments
Thanks for reading, and thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor.
-
The overhead is minimal, but it is not completely zero. The suggested idiom for converting to a
NewTypeis to call it like a function, as I've done in these examples, but if you are wanting to use this pattern inside of a hot loop, you can use# type: ignore[return-value]comments to avoid that small cost. β©
22 May 2026 12:33am GMT
21 May 2026
Django community aggregator: Community blog posts
Utrecht (NL) Python meetup summaries
I made summaries at the 4th PyUtrecht meetup (in Nieuwegein, at Qstars this time).
Qstars IT and open source - Derk Weijers
Qstars IT hosted the meeting. It is an infra/programming/consultancy/training company that uses lots of Python.
They also love open source and try to sponsor where possible.
One of the things they are going to open source (next week) is a "cable thermal model", a calculation method to determine the temperature of underground electricity cables. The Netherlands has a lot of net congestion... So if you can have a better grid usage by calculating the real temperature of cables instead of using an estimated temperature, you might be able to increase the load on the cable without hitting the max temperature. Coupled with "measurement tiles" that actually monitor the temperature.
They build it for one of the three big electricity companies in the Netherlands and got permission to open source it so that the other companies can also use it. They hope it will have real impact.
He explained an open source project he started personally: "the space devs". Integrating rocket launch data and providing an API. Now it has five core developers (and got an invitation to the biggest space conference, two years ago!)
Some benefits from writing open source:
- You build your own portfolio.
- You can try new technologies. Always nice to have the skill to learn new things.
- You improve your communication skills (both sending and receiving).
- You can make your own decisions.
- You write in the open.
- Perhaps you help others with your work.
- You could be part of a cummunity.
- It is your code.
How to start?
- Reach out to other communities.
- Read and improve documentation.
- Find good first issues.
- Be proactive.
- Don't be afraid to ask questions (and don't let negative comments discourage you).
When working on open source, make sure you take security serious. People nowadays like to use supply chain attacks via open source software. So use 2FA and look at your deployment procedure.
Learning Python with Karel - EiEi Tun H
What is Karel <https://github.com/alts/karel>)? A teaching tool/robot for learning programming. You need to steer a robot in an area and have it pick up or dump objects. And... in the meantime you learn how to use functions and loops.
Karel only has a turn_left() function. So if you want to have it turn right, it is handy to add a function for it:
def turn_right():
turn_left()
turn_left()
turn_left()
Simple, but you have to learn it sometime!
In her experience, AI can help a lot when learning to code: it explains stuff to you like you're a five-year-old, and that's perfect.
If you want to play with Karel: https://compedu.stanford.edu/karel-reader/docs/python/en/ide.html
JSON freedom or chaos; how to trust your data - Bart Dorlandt
For this talk, I'm pointing at the PyGrunn summary I made three weeks ago. I liked the talk!
Practical software architecture for Python developers - Henk-Jan van Hasselaar
There are several levels of architecture. Organization level. System level. Application, Code.
Cohesion: "the degree to which the elements inside a module belong together". What does it mean? Working towards the same goal or function. Together means something like distance. When two functions are in separate libraries, they're not together. It is also important for cognitive load.
Coupling: loose coupling versus high coupling. You want loose coupling, so that changes in one module don't affect another module.
You don't really have to worry about coupling and cohesion in existing systems that don't need to be changed. But when you start changing or build something new: take coupling/cohesion into account.
Software architecture is a tradeoff. Seperation of concerns is fine, but it creates layers and thus distance, for instance.
Python is one of the most difficult languages when it comes to clean coding and clean architecture. You're allowed to do so many dirty things! Typing isn't even mandatory...
He showed a simple REST API as an example. Database model + view. But when you change the database model, like a field name, that field name automatically changes in the API response. So your internal database structure is coupled to the function at the customer that consumes the API.
What you actually need to do is to have a better "contract". A domain model. In his example code, it was a Pydantic model with a fixed set of fields. A converter modifies the internal database model to the domain model.
You can also have services, generic pieces of code that work on domain models. And adapters to and from domain models, like converting domain models to csv.
Finding the balance is the software architect's job.
What is the least you should do as a software developer? At least to create a domain layer. Including a validator.
There was a question about how to do this with Django: it is hard. Django's models are everywhere. And you really need a clean domain layer...
21 May 2026 4:00am GMT
My PyCon USΒ 2026
A timeline of my PyCon US 2026 journey, in Long Beach (US), told through the Mastodon posts I shared along the way.
21 May 2026 3:00am GMT
04 Apr 2026
Planet Twisted
Donovan Preston: Using osascript with terminal agents on macOS
Here is a useful trick that is unreasonably effective for simple computer use goals using modern terminal agents. On macOS, there has been a terminal osascript command since the original release of Mac OS X. All you have to do is suggest your agent use it and it can perform any application control action available in any AppleScript dictionary for any Mac app. No MCP set up or tools required at all. Agents are much more adapt at using rod terminal commands, especially ones that haven't changed in 30 years. Having a computer control interface that hasn't changed in 30 years and has extensive examples in the Internet corpus makes modern models understand how to use these tools basically Effortlessly. macOS locks down these permissions pretty heavily nowadays though, so you will have to grant the application control permission to terminal. But once you have done that, the range of possibilities for commanding applications using natural language is quite extensive. Also, for both Safari and chrome on Mac, you are going to want to turn on JavaScript over AppleScript permission. This basically allows claude or another agent to debug your web applications live for you as you are using them.In chrome, go to the view menu, developer submenu, and choose "Allow JavaScript from Apple events". In Safari, it's under the safari menu, settings, developer, "Allow JavaScript from Apple events". Then you can do something like "Hey Claude, would you Please use osascript to navigate the front chrome tab to hacker news". Once you suggest using OSA script in a session it will figure out pretty quickly what it can do with it. Of course you can ask it to do casual things like open your mail app or whatever. Then you can figure out what other things will work like please click around my web app or check the JavaScript Console for errors. Another very important tips for using modern agents is to try to practice using speech to text. I think speaking might be something like five times faster than typing. It takes a lot of time to get used to, especially after a lifetime of programming by typing, but it's a very interesting and a different experience and once you have a lot of practice It starts to to feel effortless.
04 Apr 2026 1:31pm GMT
16 Mar 2026
Planet Twisted
Donovan Preston: "Start Drag" and "Drop" to select text with macOS Voice Control
I have been using macOS voice control for about three years. First it was a way to reduce pain from excessive computer use. It has been a real struggle. Decades of computer use habits with typing and the mouse are hard to overcome! Text selection manipulation commands work quite well on macOS native apps like apps written in swift or safari with an accessibly tagged webpage. However, many webpages and electron apps (Visual Studio Code) have serious problems manipulating the selection, not working at all when using "select foo" where foo is a word in the text box to select, or off by one errors when manipulating the cursor position or extending the selection. I only recently expanded my repertoire with the "start drag" and "drop" commands, previously having used "Click and hold mouse", "move cursor to x", and "release mouse". Well, now I have discovered that using "start drag x" and "drop x" makes a fantastic text selection method! This is really going to improve my speed. In the long run, I believe computer voice control in general is going to end up being faster than WIMP, but for now the awkwardly rigid command phrasing and the amount of times it misses commands or misunderstands commands still really holds it back. I've been learning the macOS Voice Control specific command set for years now and I still reach for the keyboard and mouse way too often.
16 Mar 2026 11:04am GMT

