12 Jun 2026
Django community aggregator: Community blog posts
Issue 341: Django 2026 Fundraising Goals
News
DSF 2026 Fundraising Goals
The Django Software Foundation is raising its 2026 annual fundraising goal from $300,000 to $500,000. The money supports the Django Fellows program, legal and trademark work, community grants and events, ongoing infrastructure, and progress toward hiring an Executive Director.
Announcing Our DjangoCon US 2026 Talks!
DjangoCon US 2026 released its tutorial and talk lineup for Aug 24 to Aug 26, with live access for online-only ticket holders and free YouTube uploads after the conference. Expect sessions spanning Django 6.1 and modern ORM patterns, performance testing, Wagtail routing, Postgres updates, and deployment topics, with the final schedule to follow soon.
Vulnerability and malware checks in uv
uv introduces uv audit to scan locked dependencies for known vulnerabilities and adverse statuses, positioned as a faster uv-native alternative to pip-audit.
Updates to Django
Today, "Updates to Django" is presented by Hwayoung from Djangonaut Space! 🚀
Last week we had 16 pull requests merged into Django by 11 different contributors - including 5 first-time contributors! Congratulations to jodizzle, Bankai, Chris Rose, esperonus-karolis and Wes P. for having their first commits merged into Django - welcome on board!
This week's Django highlights: 🦄
- Made DjangoJSONEncoder consistently omit the .000 fractional-second suffix when serializing datetime and time values that have no meaningful microseconds. (#37108)
- Added a new listurls management command to display all registered URL patterns in a Django project. 🐍 (#28800)
- Limited the number of related objects shown in inline formset validation error messages to prevent excessively long error output. (#36984)
- Changed SIGNED_COOKIE_LEGACY_SALT_FALLBACK to default to False and began deprecating the transitional compatibility setting. (CVE-2026-6873)
Releases
Python 3.14.6 and 3.13.14 are now available!
Python 3.14.6 is out as the sixth 3.14 maintenance release, with about 179 bugfixes plus build and documentation updates since 3.14.5. Python 3.13.14 follows as the fourteenth 3.13 maintenance release, adding around 240 bugfixes along with build and documentation changes since 3.13.13.
Core Dispatch #5
Python 3.15.0 beta 2 landed June 2, with another round of milestones due June 9 and June 23. Expect the practical stuff in 3.15 including a fixed O(n^2) blowup in unicodedata.normalize, XML multi-byte encoding support, and fresh deprecation warnings around ast and abc abstract* helpers, alongside an initial documented Python security policy in the Devguide.
Sponsored Link
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 Local LLM Setup - Fast Agentic Development with No Token Bill
From Peter Grandstaff, a write-up of his maxxed-out local LLM setup using an Nvidia GeForce RTX 4090 video card. A very cool setup and one which many of us will likely be using some version of in the future.
Logical optimizations
Nested if blocks can often be rewritten as a single conjunction, but only when each if fully owns the body with no else or trailing code.
Browser Push Notifications for a Django Website
Set up browser push notifications end to end: store push subscriptions in Django, register/unregister via authenticated endpoints, and send notifications from a Huey background task using pywebpush with VAPID.
Anything new?
Maintainer Matthias Kestenholz explains why stepping away from django-mptt is hard, and how entitlement in issue trackers turns "free labor" into a burnout trap.
PyCon US 2026 - Open Source Community in Long Beach - Peter Grandstaff
Another one from Peter Grandstaff, a day-by-day PyCon US 2026 trip focused on building Django connections, sponsorship work for DjangoCon US, and catching talks on developer experience and open source community support.
Django Forum
Switch to Playwright tests for integration testing
This project aims to modernize Django's integration testing by introducing Playwright as an alternative to Selenium.
Proposal: Leverage Oracle Test Pilot for Django CI
A proposal from the Oracle Test Pilot for Third-Party Software program building Oracle Test Pilot to provide access to the latest versions of the Oracle databases to Django on GitHub, for free.
Django Fellow Reports
Natalia Bidart
This week was quite intense, with most of the focus 🔍 on getting the security release out the door 🚪. Issuing the release for the 5 CVEs took a fair amount of coordination and attention to detail, and definitely consumed a good chunk of brain power 🧠 ⚡.
Alongside that, there were a number of meetings throughout the week, so overall it was a mix of high-focus release work and keeping in sync with the different groups 🤝. Bonus: the final DEP 0018 for MAILERS was approved, moved to the accepted folder, and merged ✅.
Jacob Walls
A highlight this week was landing the listurls command modeled on django-extensions. Many tickets triaged, reviewed, authored, and discussed.
Events
Announcing Our DjangoCon US 2026 Talks!
The complete lineup of talks, August 24-26, is now live! So many great talks coming up.
Django Meetup Vol. 78 / Beyond Boilerplate: Building Maintainable CRUD in Django
Django Meetup Cologne Vol. 78 will take place on the 16th of June 2026, online and in person.
Django Job Board
Founding ML/Data Scientist (Remote, UK) at MyDataValue 🆕
Projects
django-helpdesk/django-helpdesk
A Django application to manage tickets for an internal helpdesk. Formerly known as Jutda Helpdesk.
emmett-framework/granian
A Rust HTTP server for Python applications.
12 Jun 2026 3:00pm GMT
Planet Python
EuroPython: June Newsletter: Talks Schedule Released
Hi all Pythonistas! 👋
We have just one month left until we all meet up in Kraków, and we've got a lot of new stuff to tell you: the schedule is available, new keynote announcements, our 25 years of EuroPython celebrations (win a free ticket!), the release of our Speaker's Orientation Workshop video on YouTube (in case you missed it!), remote ticket availability, a reminder about ticket prices (going up on June 26th!), plus plenty more 💚
🎉 Talk Schedule Available
Let's start with the big one: the programme team have been working tirelessly to get the talk schedule finalised, and you can now read it, in full, over on our website. The talks this year were selected from a record breaking number of submissions, and we are really excited about the number of topics covered from such a wide range of speakers.
👉 Start noting down your 'must see' favourites now, and plan out your &aposjourney&apos through the conference: https://ep2026.europython.eu/schedule/
🎤 Keynote Announcements
Guido van Rossum, Łukasz Langa, Pablo Galindo Salgado, and Leah Wasser were already on the schedule as keynote speakers, but we've now confirmed three more! We are very excited to have the following speakers joining us in Kraków:
William Woodruff is a Member of Technical Staff at Astral, where he works on building high-performance, secure tooling that is modernising the Python developer experience. Prior to Astral, he was an Engineering Director at Trail of Bits, leading high-impact security initiatives across open-source ecosystems.

Marlene Mhangami is a Senior Developer Advocate at Microsoft and GitHub, where she focuses on the cutting edge of Python and AI. As a computer scientist, keynote speaker, and explorer, she is a massive driving force behind community growth across the globe.

Imogen Wright is a Senior Engineer at Amazon EC2, where they focus on making incredibly complex systems behave. Their career spans over two decades of solving high-stakes challenges across theoretical physics, HIV drug resistance, COVID genomics, cloud technologies, and even ad tech!

All of our keynote speakers are some of the most respected leaders in the industry and in their specific fields, and we are privileged to have them join us at EuroPython 2026. We are so pleased to be able to put together such an incredible line up! 🐍💚
⌛ Get Your Ticket Before Prices Increase
We know that many of you have already purchased tickets (thank you!) but a quick reminder to those who have yet to do so: ticket prices will increase on June 26th and our Late Bird prices will apply, so if you're thinking of coming, it definitely makes sense to secure your ticket before then!
👉 Purchase your tickets today on the EuroPython 2026 website: https://ep2026.europython.eu/tickets/
💻 Remote Ticket Sales
If you are joining us remotely this year, just a heads up that remote sales will start next Monday, 15th June. The tickets will be available to purchase on our website as soon as Monday rolls around!
🎂 25 Years of EuroPython
We are celebrating 25 years of EuroPython this year (I know, we can't believe it either!), and we have a few fun things planned to make it special, including a chance to win a free ticket - which you can transfer to someone else, if you've already got yours!
📜 The Oldest Badge Contest
Are you one of those people who keeps your badges from previous conferences? It might be about to pay off: we will be having a contest to find the Oldest EuroPython Badge amongst all attendees this year! Dig around in your drawers, boxes, attic or other archive and find the oldest EuroPython badge (with your name on it…) that you can. Whoever has the oldest will win the contest!
🎫 Free Ticket Competition: Your EuroPython Experiences
We're running a competition - open to anyone who has attended EuroPython in the past - who can record a short video telling us about their most impactful EuroPython experience! The competition is open to anyone who has attended EuroPython before, and is really easy to enter. No need for anything very fancy: just record yourself talking and tell us why your particular experience at EuroPython made such an impact on you.
The competition will be closing on June 21st (extended!), so you've still got plenty of time to enter.
👉 For the details, see the entry form: https://forms.gle/WNPErwWtpE1oPVhD9
💭 Taking a Trip Down Memory Lane
Finally, we thought you might appreciate a little video we've posted on YouTube recently: Jonathan Hartley spoke to us at PyCon US about one of his favourite EuroPython experiences of the past:
🦄 Django Girls Workshop Sign Up
We are sure many of you are already aware of Django Girls and the great work that they do in making Python and Django more accessible to people around the world (often but not only girls!), and we are super pleased to announce that they will be running a workshop at EuroPython 2026 in Kraków!
👉 The workshop is a full day, on 18 July (a sprint day), and you can register on the Django Girls website: https://djangogirls.org/en/krakow2/
🏃♀️ Women in Python 5K Run
On Thursday 16th July there will be a group run with the aim of enabling some friendly networking and friendship building between women in the Python community.
It is open to runners of all experience levels, and will be a nice route around Kraków - along the river and at walking distance from the conference venue. If you are interested, please fill out the form below to help us prepare better (no commitment required - yet!), and we will send details of how to confirm your place closer to the time.
We'd like to thank our sponsor Arm for supporting this run.
👉 Register your interest here: https://forms.gle/bcsBTtNX1crEQhbw8
⭐ On-Site Volunteering
A big thank you to all who responded to our call for on-site volunteers, and we are now considering the applications. We had over 110 applications (far more than last year), and we loved to see applications from countries all over the world! 💚
We are now selecting volunteers, and you will receive notification of the status of your application in the following week (13-19th June). We will contact everyone who applied, even if you were not selected.
Thanks again to all of you - volunteers are the heart of EuroPython and we could not run the conference without you. ✨
👩🏫 Speaker Orientation Workshop
The EuroPython Speaker Orientation ran on the 3rd June 2026, and contained valuable tips from some of the most experienced speakers in our community. The panel spent an hour and a half giving practical advice on preparing talks, creating effective slides, managing nerves, engaging audiences, and handling Q&A sessions.
Cheuk Ting Ho, Rodrigo Girão Serrão, and Sebastian Witowski answered questions from new and returning speakers, sharing insights and lessons from their own conference speaking journeys.
Thank you to our amazing panel and everyone who joined us - we can't wait to see you in Kraków!
💚 Financial Aid Round Up
This year, we received a record-high 217 financial aid applications across two rounds. We know how much care, hope, and effort goes into every application, and our financial aid team have worked hard to review them all with the attention they deserve.
We're happy to share that all financial aid decisions have been sent out. With the €35,000 budget provided by the EuroPython Society, we have issued 84 grant offers. We are grateful to be able to support so many members of our community, and sincerely hope that all grantees will be able to join us in Kraków this summer to learn, connect, and celebrate the 25th anniversary of EuroPython.
To everyone who applied but was not offered a grant: we are very sorry for the disappointing news. If we miss you in Kraków, we still very much hope you'll be part of the conference and connect with us remotely.
📺 EuroPython YouTube Channel
We&aposve been posting a lot of new content over on the EuroPython YouTube Channel, including some fun short interviews from PyCon US:
- Carol Willing talks about her favourite EuroPython moment
- Can you believe that some people have attended this many EuroPython conferences?
- What fun things were planned at PyCon Italia this year?
👉 Subscribe and keep up with our latest videos: https://www.youtube.com/@EuroPythonConference
💬 Last Call for Sponsor Booths
We&aposre down to our last few sponsorship slots with booths! Want to meet the Python community face-to-face at EuroPython 2026? This is your final chance to connect with our thousands of attendees.
👉 Email sponsoring@europython.eu before the slots are gone!
⚙️ Reminder: Rust Summit
Registration is still open for the full-day Rust summit, exploring the intersection of Rust and the Python ecosystem - it is a 'must-see' for anyone interested in how Rust is turbocharging Python tooling and Python computational libraries in 2026.
This summit is designed for developers who already possess some practical experience in these topics and are looking to deepen their expertise, share lessons learned, and contribute to the community&aposs collective knowledge.
👉 Register for the Rust Summit: https://ep2026.europython.eu/session/rust-summit-at-europython
🤝 Community Partners
🦬 PyStok
PyStok #83 lands on June 17th at 18:00 at Zmiana Klimatu in Białystok - and free registration is officially live!
Between the "speed dating" networking, JetBrains giveaways, and the legendary "Podlaskie afterparty", it's the perfect spot to soak up those unique North-East Polish vibes and talk Python and AI with the local crowd.
👉 Grab your spot at https://pystok.org/najblizsze-wydarzenie
📣 Community Outreach
The EuroPython Society has continued our world tour of Python events, and as always, thank you to everyone that came to speak to us!
🇺🇸 PyCon US
Several members of the EuroPython Society were at PyCon US in Long Beach, and we were very happy to have a stand at the conference and meet friends old and new. We know many of you will be joining us in Kraków as well, and we look forward to seeing you again!

👉 For more information about what we got up to PyCon US, check out our post on the EuroPython Society blog: https://europython-society.org/europython-society-at-pycon-us-2026/
🇮🇹 PyCon Italia
The EuroPython Society also had a stand at PyCon Italia, which we shared with the Django Software Foundation, and we were pleased to see such interest in our stickers, which we managed to 'sell out' of on the 2nd day of talks! If you want more stickers, you know where to go!

🎁 Sponsor Spotlight
We&aposd like to thank our three Platinum sponsors for supporting EuroPython:
Manychat builds AI-powered chat automation for 1M+ creators and brands at real production scale.
Open Source enables Microsoft products and services to bring choice, technology and community to our customers.
Vercel provies Agentic Infrastructure for every app and agent. They are the creators of AI SDK, Next.js, Turborepo, and v0.
👋 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
Okay, what a packed edition this one has been! It's all go here at EuroPython and as you can see, we have so much in store for you. Don't forget: get your tickets before the prices increase, and we can't wait to see you really, really soon! 🐍💚
Cheers,
The EuroPython Team
Sign up for EuroPython Blog
The official blog of everything & anything EuroPython! EuroPython 2026 13-19 July, Kraków
No spam. Unsubscribe anytime.
12 Jun 2026 9:41am GMT
Hugo van Kemenade: I'm delighted to rejoin the Sovereign Tech Fellowship
I'm happy to rejoin the Sovereign Tech Fellowship!
I was one of six participants in the 2025 pilot to pay maintainers of critical open source technologies in the public interest. By all accounts this first cohort was a resounding success, and I'm glad to see the programme continue.
It was wonderful to be part of the inaugural Sovereign Tech Fellowship, and incredibly beneficial to my projects: it gave me the time to focus on releasing Python 3.14 and 3.15 smoothly, to mentor and onboard others, and to support the wider community.
2025 impact #
The 2025 evaluation report covers all six of us and the benefits of the programme at a higher level. Here's some of the specific things I achieved.
I was happy with how the big Python 3.14.0 release went. This is in part from having a good team to work with, and building on the past, but no doubt also due to being able to focus and invest time thanks to the Fellowship.
On many occasions, having time to dedicate to the role meant I could prioritise things as they occurred. For example, when needing to make expedited releases, I could dedicate time to go through all the necessary prep, and make the release without any stress of fitting it in around a regular job. Similarly, when last-minute problems came up on release day, such as newly-committed code not passing tests, I didn't need to rush, and could contact the contributor to arrange a fix. Some other release managers had reverted similar changes to let the contributor try again for a later release, but there was less pressure for me and I could wait longer.
I was able to mentor other project members, such as helping onboard the next release manager, and also answer questions for other triagers. I promoted two new triagers in different projects. Other community members sometimes asked me about how to contribute. I attended many community "office hours" meetings and Monthly Conference Organisers' calls to share what's going on and answer questions, and likewise blogged and shared on social media such as Mastodon, Bluesky and LinkedIn. I was able to attend many conferences and give talks about the upcoming release, and discuss with other attendees what happens with Python releases and the project in general. This all helps improve transparency. I also chaired many monthly Docs Working Group meetings, and attended many other meetings from different projects.
I was able to make many improvements in the release process, through additional automation and testing to remove tedious manual steps. I've improved the accessibility of websites visited by tens of millions per month.
I created a triage dashboard that helped us close hundreds of issues, and also complete forgotten backports including security fixes.
I was also able to invest time on non-technical, social, organisational and governance improvements. I'm proud my proposal was accepted to alternate the Language Summit between PyCon US and EuroPython, rather than always being in the US, to improve the diversity of voices of who will shape the future of Python. The 2026 summit will be held at EuroPython and I'm helping organise.
Since 2009, the summit has been a one-day event that takes place at PyCon US before the main conference days. It has also been held at EuroPython twice, in 2010 and 2011. The PSF mission is "to support and facilitate the growth of a diverse and international community of Python programmers", and not all potential attendees can travel to the US each year. This proposal took a lot of work:
- In November 2024, the core team discussed on Discord the possibility of alternating the summit between PyCon US and EuroPython. People were in favour, but said it would need to be discussed at the summit at PyCon US in May 2025.
- In March 2025, I asked for the topic to be added to the agenda, as I wasn't attending.
- In May, the discussion took place. The minutes simply said: "Watch out for a Discourse thread to discuss this."
- In July, during EuroPython, I asked summit attendees what the impression was, and they said people were in favour. I also spoke with the chair of EuroPython Society about the summit requirements, and they said they'd be happy to host us.
- In August, because no Discourse thread had appeared, I opened a proposal to alternate.
- In September, during the Steering Council Q&A at the Core Team Sprint, I asked about next steps. The consensus was for the SC to open a formal poll amongst the core team.
- In October, the SC opened a poll for core team members.
- In November, the poll concluded overwhelmingly in favour of alternating.
- In December, the SC approved my request. I volunteered to help organise the summit and opened discussions with the EuroPython Society to make it happen in 2026.
I had more free time to spend on non-open source things, but also more free time to help the local Python community such as by co-organising two local meetups. One person I nominated became a Fellow of the Python Software Foundation and another of the EuroPython Society, which recognises the importance of community work.
Finally, I enjoyed our monthly Fellowship meetings where the six of us all gave a summary of our last month's work. Similarly, it was great to meet most of them in person along with people from the Agency at the event to mark the inaugural Sovereign Tech Fellowship cohort and hear the results of the evaluation report.
Arbitrary statistics #
On GitHub:
- Total contributions: 6,642
- Issues created: 90
- PRs created: 901
- Issues closed: 446
- PRs merged: 1,401
- PRs closed: 142
- Total issues involved with: 1,409
- Total PRs involved with: 4,095
- Repositories affected: 409
Made 55 releases:
- 13 of Python 3.14
- 3 of Python 3.15
- 39 of PyPI projects
Started maintaining:
Archived:
Attended eight conferences in Berlin (FOSS Backstage and Design), Bologna (PyCon Italia), Prague (EuroPython), Athens (PyCon Greece), Manchester (PyCon UK), Tallinn (PyCon Estonia), Jyväskylä (PyCon Finland) and Stockholm (PyCon Sweden)
- On a discussion panel at one
- Gave a lightning talk at five
- Announced PyCon Finland at four
- Helped new contributors at sprints at three
- Hosted a barcamp session at one
- Helped organise one by reviewing talks and through promotion
- Volunteered at one
Attended three online conferences:
- March: SustainOSS Virtual Forum
- May: Maintainer Summit
- December: PyLadiesCon
Other events:
- September: Core Team Sprint in Cambridge
- December: Sovereign Tech Agency event in Berlin to mark the inaugural Fellowship cohort
Meetups:
- Co-organised 16 meetups for two groups, one which we restarted in 2025
- Attended 27 meetups of 11 groups in four cities and three countries
- Gave one long talk and four lightning talks
- Organised 12 monthly meetings, chaired 9, attended 10
- Attended two meetings
Published 17 blog posts:
- February: How to delay a Python release
- February: I'm excited to join the Sovereign Tech Fellowship
- February: Improving licence metadata
- March: Free-threaded Python on GitHub Actions
- April: My most used command-line commands
- May: PEPs & Co.
- June: Run coverage on tests
- August: EuroPython 2025: A roundup of writeups
- September: Ready prek go!
- October: Releasing Python 3.14.0
- October: Three times faster with lazy imports
- November: Python Core Sprint 2025
- November: Setting secrets in env vars
- December: Steering Council election
- December: Steering Council results
- December: And now for something completely different
- December: Replacing python-dateutil to remove six
Reported 67 accounts to GitHub for spam/abuse/inauthentic activity.
2026 and beyond #
This time we're 14 Fellows, and not only maintainers but also community managers and technical writers. It's great that Python core dev Stan Ulbrych and PSF director Georgi Ker are also joining, and I'm looking forward to meeting the other Sovereign Tech Fellows.
I'm really pleased to again be working with the Sovereign Tech Agency. They're showing the world some of the ways we can improve open source and critical digital infrastructure, through a range of different programmes. Their success has informed the proposal for an EU Sovereign Tech Fund (EU-STF), and they have also helped shape the European Digital Infrastructure Consortium for digital commons (DC-EDIC), with an EU-STF pilot kicking off later this month which builds on their experience. And it's good to see the focus on maintenance and long-term sustainability in the brand new EU Open Source Strategy, announced just last week.
And by the way, the Sovereign Tech Agency are currently hiring, check out their open positions.
Header photo by Jan Michalko.
12 Jun 2026 7:35am GMT
11 Jun 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.
11 Jun 2026 10:00pm GMT
10 Jun 2026
Django community aggregator: Community blog posts
Running Fallout London on Bazzite
I'm a huge Fallout fan, and Fallout London is one of the most impressive mods I've seen in years: a full DLC-sized expansion set in post-apocalyptic London, made by a community team. Running it on Bazzite (my gaming OS of choice) wasn't completely straightforward, so here's what actually worked for me. Consider this a note to future me, but hopefully it saves someone else an afternoon of trial and error.
What you'll need
- Bazzite installed on your machine
- Heroic Games Launcher
- Fallout 4 (the mod requires it as a base)
- The "Fallout London One Click Mod" (available through Heroic)
The steps
1. Install Heroic Games Launcher
If you don't have it yet, install Heroic from the Bazzite app store or via Flatpak. It's a fantastic open-source launcher that handles GOG, Epic, and Amazon games, and it plays very nicely with Proton.
After you install it, login with your GOG account

2. Install the Fallout London One Click Mod
Search for "Fallout London" in Heroic and install the One Click Mod version. This bundles everything together so you don't have to manually manage mod files. Let it do its thing.

3. Disable UMU (yes, it needs to be disabled)
This is the counterintuitive part. Once the mod is installed, go to its settings in Heroic, then the Advanced tab. You'll see an option called "Disable UMU". Enable it (meaning: check the checkbox to disable UMU). I know, "enable the disable" is a confusing way to phrase it, but that's what it says.
Without this, the game won't launch correctly on Bazzite.

4. Run it once in Desktop Mode
Before adding it to Steam, launch the game once directly from Heroic while you're in Desktop Mode. This lets everything install and configure properly: shaders, redistributables, the works. Wait until you're actually in the game and confirmed it runs without issues, then close it.
5. Add to Steam
Click the three-dot menu on the game in Heroic and select "Add to Steam". From this point on you can launch it from Game Mode like any other game in your library.

Play!
That's it. Boot into Game Mode, find Fallout London in your library, and enjoy one of the best Fallout experiences made outside of Bethesda.


See you in the next one!
10 Jun 2026 5:00am GMT
09 Jun 2026
Django community aggregator: Community blog posts
Logical optimizations
The second article in the series. The first was about control flow; this one stays with the same tactic - reshaping code - one layer down, at the condition. Here: merging ifs, factoring shared decisions, and dropping checks that earn nothing. The Boolean algebra of conditions - De Morgan and friends - is a different lever, and gets its own installment next time.

09 Jun 2026 11:00am GMT
Planet Twisted
Hynek Schlawack: How to Ditch Codecov for Python Projects
Codecov's unreliability breaking CI on my open source projects has been a constant source of frustration for me for years. I have found a way to enforce coverage over a whole GitHub Actions build matrix that doesn't rely on third-party services.
09 Jun 2026 12:00am GMT
22 May 2026
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
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


