This tutorial looks at how to build a Django app that takes website screenshots using Playwright and Celery.

04 Nov 2026 4:28am GMT

As a research project this year at Caktus, we've been experimenting with serving open-weight language models on our own hardware. In this post, we'll walk through the hardware, the Docker Compose stack that serves our models, the Gemma and Qwen configurations we tested, our benchmarks, and the configurations we use in pi.dev and VS Code.

30 Oct 2026 6:00pm GMT

News

Python 3.15.2, 3.14.10, 3.13.18, 3.12.16, and 3.11.18 are out

A second round of expedited security releases, five days after the last: the ssl module now blocks the compromised eMudhra intermediate CA keys outright, so pip is protected even before you upgrade it. They also fix a tarfile.tar_filter bypass using links that replace the destination and reject negative-version cookies in http.cookiejar.

Announcing PSF Community Service Award Recipients!

Five new Community Service Awards go to Abhijeet Mote, Elena Williams, Hugo van Kemenade, Kevin Horn, and Sarah Abderemane. Two are familiar Django names: Elena organized the second Django Girls event ever held and now sits on Django's Code of Conduct committee, and Sarah co-founded Djangonaut Space, maintains djangoproject.com, and served as DSF Vice President in 2025.

Django Software Foundation

Natalia Bidart - Planned short-term leave

After more than three years as a Django Fellow, Natalia is taking November through January off to rest and recover, with the other Fellows and Django's teams and working groups covering in the meantime. She returns in February, ready to serve as release manager for Django 2028.

Python Software Foundation

Higher limits for organization projects

Projects owned by a PyPI organization now get 200 MB per file and 20 GB per project, double the personal limits, with nothing to turn on. Move a project out of the organization and it drops back, though any increase support already granted stays in place.

PyPI now limits versions to 128 characters

New uploads need a normalized version of 128 characters or less. Only 2 of PyPI's roughly 9.9 million releases are that long, existing releases are untouched, and pip and uv need no changes.

Wagtail CMS News

A Wagtail demo in your browser

Thibaud Colas's bakerydemo-webassembly runs Django, Wagtail, and the whole demo site in your browser with Pyodide, saving data to IndexedDB so nothing leaves your device. Log in at /admin/ with admin / changeme: it's a sandbox for learning and demos, not production.

Wagtail and the eMudhra CA key compromise

Wagtail makes outbound HTTPS calls through requests, which trusts certifi's bundled certificates rather than your operating system's, so an OS update alone won't stop it trusting eMudhra. Jake Howard covers what to upgrade, and if you deploy in containers, a rebuild picks up the patched base images.

Updates to Django

Today, "Updates to Django" is presented by Hwayoung from Djangonaut Space! 🚀

Last week we had 21 pull requests merged into Django by 13 different contributors - including 4 first-time contributors! Congratulations to gerry132, Helmi Lakhder, Aman Kumar Jain and Sanskar Kharya for having their first commits merged into Django - welcome on board!

News in Django:

• Django 6.1 now supports Python 3.15 (#36664).
• Fixed a bug in Django 6.2 where CSP directives containing only CSP.NONCE were omitted when the nonce was unused, potentially allowing a less restrictive fallback policy. These directives now emit 'none' instead (#37395).
• Improved accessibility of the Unix/Windows console tabs in Django's documentation, adding keyboard navigation and improving support for high contrast mode and right-to-left languages (#35874).

Django Fellow Reports

Django Fellow Report - Jacob

Jacob spent much of the week on security patches but still merged initial support for the HTTP QUERY method and approved Sarah's final tweaks to multiline template tags. He also marked a FETCH_PEERS bug that can overwrite deferred-field changes as a release blocker.

Django Fellow Report - Sarah

Sarah added a pull request limit for new contributors, part of her proposed Trac changes to curb irresponsible AI-led contributions, and added a "Low" severity to Trac. She also authored fixes for CSP nonces on streaming responses and overly broad permissions in file_move_safe(), and engaged in six security issues.

Django Fellow Report - Natalia

Wrapping up before her break, Natalia landed the first stage of the docs' console tab accessibility improvements and the 6.1 release note for RedirectURLMixin. She also fixed makemessages with non-ASCII filenames on Windows, escaped database errors logged by Q.check(), and patched a confirmed low-severity security issue.

Sponsored

Django for Beginners, 6th Edition

The sixth edition is out now, available in digital and paperback formats. It features two new chapters, completely updated for Django 6.1+, and more. Read the first four chapters for free to try it out.

Articles

Django as a simple static site builder

Radiac wires nanodjango, django-nanopages, and django-distill into a Django-native answer to Jekyll: app.pages("/", path="pages") maps Markdown and HTML files onto URLs with frontmatter for titles and templates, and distill renders the lot to static output. A PEP 723 block means uv run website.py needs no install first.

How I decide which Python and Django versions I want to support

Matthias Kestenholz keeps projects and dev machines on the newest Python, but supports old versions in libraries for as long as it's cheap, since people on managed hosting can't always upgrade. He drops a version only to trim CI time or to use a new feature, which currently puts most of his packages at Python 3.10+ and Django 3.2 or 4.2+.

What Our Djangonauts Shipped on Django Packages

A long-overdue tour of what three Djangonaut Space contributors, Farhan Ali Raza, Felipe de Morais, and Victoria Cruces, built in summer 2024: one-click htmx favorites you can share on your profile, a Most Liked Packages page, OpenSearch so you can search from the address bar, and documentation links pulled from PyPI. Every one of their PRs is listed at the end.

Why use open source at all with AI?

Tim Schilling had AI build a clunky but free teleprompter in six prompts, which made him ask why anyone needs open source now. His answer: quality comes from deliberating over decisions and edge cases, which AI can't do for you, and open source lets you inherit years of that deliberation for free.

Python's experimental JIT to be removed

The Steering Council gave the JIT team six months to get a standards-track PEP accepted or see the JIT removed from CPython's main branch. After the council asked for more on platform parity, user-visible behavior changes, and security, the authors withdrew PEP 836 on October 19, so the JIT is likely to come out early in the 3.16 cycle.

CSS-Tricks has a new owner!

Four years after DigitalOcean bought it from Chris Coyier, CSS-Tricks is independent again under longtime editor Geoff Graham, who is making it his full-time job. Expect one or two articles most weeks, a beginner HTML/CSS course, memberships, the return of the newsletter, and a reopened guest writing form.

Events

Django Day São Paulo 2027

São Paulo's first event dedicated entirely to Django is coming in the first half of 2027. Over the next few weeks the organizers will announce the official date and venue, open the call for speakers, and start ticket sales, so follow them on Mastodon for updates.

Podcasts

Talk Python #567: Personal AI Agents for Pythonistas

Our own Jeff Triplett joins Michael Kennedy to talk about Hermes, the self-hosted Python agent you program by talking to it, which runs 24/7 on a box at home and wakes every 15 minutes to handle chores like morning briefings. Jeff runs his on a spare Mac Mini and a few Orange Pi boards, and it now talks to Django News, DjangoTV, and the Django Job Board over MCP.

Real Python Podcast #316: The Future of Python Security

Seth Larson, the PSF's Security Developer in Residence, explains how PEP 811 formalized the Python Security Response Team's reporting and triage, and how LLMs are driving up the volume of vulnerability reports. He also covers trusted publishing on PyPI, SBOMs under PEP 770, and practical advice for locking down your CI/CD.

Videos

DjangoCon Europe 2026

The talks from Athens are now on DjangoTV, including both keynotes, auto-prefetching with Django 6.1's field fetch modes, partitioning very large tables with PostgreSQL, shipping Django as a desktop app, and a community conversation on Django and AI.

DjangoCon US 2026

The Chicago videos are out too: Karen Tracey's keynote on Django 6, Natalia Bidart on HTMX without betraying your Django views, the Django/FastAPI debate, search-as-you-type across 54 million names, and Will Vincent on modern Django deployments, plus hallway interviews with the community.

Django Job Board

Two new roles at webbyfox consultancy lead the board this week, alongside the PSF's CPython Developer in Residence opening and senior Python seats at Camden Kelly Staffing and Manychat in Barcelona.

Senior Python Engineer at webbyfox consultancy 🆕

AI Engineer at webbyfox consultancy 🆕

CPython Developer in Residence at Python Software Foundation

Senior Software Engineer (Python, React & AI) at Camden Kelly Staffing

Senior Python Engineer (Barcelona-based / Relocation support to Barcelona) at Manychat

Projects

Static Site Generators

The Django Packages grid for turning a Django site into flat HTML you can host on a CDN or GitHub Pages with no Django process running. django-distill leads on stars, django-bakery on forks, and django-freeze saw the most recent release, with django-nanopages the newest arrival at beta.

makinacorpus/django-leaflet

Use Leaflet in your Django projects

Sponsor Django News

Reach 4,300+ Django developers every Friday. See sponsorship details and rates.

30 Oct 2026 3:00pm GMT

News

Python 3.15.1, 3.14.9 and 3.13.17 are now available

Expedited security releases on October 21, carrying pip 26.2.2 and certifi 2026.10.19 to drop the compromised eMudhra CA. 3.13 is the odd one out: it had just entered security-only mode, where pip is not normally updated, so the team cut fresh installers anyway. 3.15.1 is also 3.15's first maintenance release, with roughly 330 fixes from 117 contributors.

Information for Python users regarding the eMudhra / emSign CA certificate security incident

The emSign root was pulled from CA bundles after eMudhra's intermediate keys turned out to be insecure, leaving older clients open to man-in-the-middle attacks against PyPI and python.org. Upgrade now: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, in every virtualenv and container image. pip is the one that matters most, since it always trusts its vendored bundle and distrusting the CA at the OS level will not help.

Eight Bits of Trust: eMudhra's CA Keys Cracked in Milliseconds

The technical story behind the advisory, and it is remarkable: each P-384 private key was 47 zero bytes followed by one non-zero byte, so Scott Helme recovered all eight in under a second on a laptop by trying 255 candidates. eMudhra blames a key ceremony script that generated a second weak keypair, picked up for the CSR because the names looked alike.

Wagtail CMS News

Wagtail 8.0.1, 7.4.4, and 7.0.10 security releases

All three landed on October 20 with the same four fixes: an authorization bypass across collections via privacy settings, formula injection in XLSX exports, mishandled ancestor restrictions in the Pages admin API, and stored XSS through third-party HTML editors. 8.0.1 adds a fifth, access restrictions on the API v3 pages endpoint, plus a batch of API v3 write fixes. Also out: 7.4.4 and 7.0.10.

Wagtail 8.1 RC1

The release candidate adds Python 3.15 support and drops 3.10. API v3 gains write support for TypedTableBlock and nested inline relations, an ImageRenditionField, and workflow operations for pages and snippets. Redirects are now auto-created only when a live page moves or is renamed; set WAGTAILREDIRECTS_AUTO_CREATE = 'always' to get the old behavior back.

Django Software Foundation

Quarterly contributor outreach

Tim Schilling posts the Steering Council's list of what needs hands for 6.2: testing CompositeField, plus review on a DEFAULT_PK_FIELD setting, moving models between apps, partitioned cookies, and HTTP QUERY support. A second list covers ideas needing technical vetting, including a task timeout API and import maps.

Django Steering Council Meeting, October 19

This week's agenda: the quarterly outreach message, the Sovereign Tech Agency Resilience Fund, the VectorField DEP, Memcached clients, Jazzband updates, and suggestions for the new Triage and Review Team.

Updates to Django

Last week we had 15 pull requests merged into Django by 10 different contributors - including 3 first-time contributors! Congratulations to Sanskar Kharya, Aman Kumar Jain and Helmi Lakhder for having their first commits merged into Django - welcome on board!

New in Django 6.2:

• Streaming responses now include configured CSP nonces in their headers, even when unused in the body. Inline scripts or styles that previously passed without a matching nonce may now be blocked or reported.
• A CSP directive whose only source is NONCE is emitted as 'none' when the nonce goes unused, instead of being dropped from the header.
• Directories created during file uploads and by the file-based cache backend now combine the requested permissions mode with the process umask, matching os.mkdir. A typical 0o022 umask turns 0o775 into 0o755, and the set-group-ID bit is no longer guaranteed, so set it on the parent directory instead. FILE_UPLOAD_PERMISSIONS is unaffected.
• The warning logged when a database error occurs while validating model constraints now escapes the message and trims it to 4096 characters.
• Python 3.15 compatibility is now documented.

New in Django 6.1:

• Fixed a crash in makemessages on Windows with non-ASCII filenames on Python 3.15+, or with UTF-8 mode enabled on older versions (#37447).
• The undocumented get_success_url_allowed_hosts() and get_redirect_url() methods from RedirectURLMixin now accept an optional request argument.

Sponsored

Django for Beginners, 6th Edition

The sixth edition was published this week, available in digital and paperback formats. It features two new chapters, completely updated for Django 6.1+, and more. Read the first four chapters for free to try it out.

Django Fellow Reports

Django Fellow Report - Jacob

Chasing a forum thread led Jacob Tyler Walls to merge a fix that reduces the cost of building many-to-many related managers. He also spotted the last tweaks needed for multiline template tags, drafted a security fix, and triaged a JSONField RecursionError on deeply nested input.

Django Fellow Report - Natalia

Natalia Bidart kept the djangodocs Sphinx cleanup and the DEP 20 release checklists moving, including CVE records that can name the first affected release per branch. The Triage and Review Team held its first meeting, and the Security and Triage teams both gained members.

Django Fellow Report - Sarah

A short week around coughs and colds, but Sarah Boyce landed CSP nonces in headers for streaming responses, corrected verbatim-block tokenization, and enforced integer expiry times for file-based sessions. She also added Lilian Tran to the security team and Shai Berger as a triager.

Python Software Foundation

Announcing Python Software Foundation Fellow Members for Q3 2026

Aldo Caneo, Donghee Na, Paul Moore, and Takayuki Shimizukawa join the Fellow roster, recognized together for maintaining libraries, writing educational material, organizing events, and mentoring. Q4 nominations close November 20, 2026; email psf-fellow at python.org with the nominee's accomplishments.

Checking email reputation, and allowing Outlook again

PyPI blocked outlook.com and hotmail.com outright in June 2024 after a bulk malware campaign, which caught legitimate users too. A donated reputation service from UserCheck now judges addresses individually, so both domains are allowed again; in its first month it rejected 62 disposable domains and 120+ throwaway addresses.

Wikis: Relaunched!

The Python, PSF, and Jython wikis went read-only in February after AI scrapers overwhelmed hosts partly still running Python 2. They are back as static sites on GitHub Pages, edited by pull request against psf/wiki, with write access going first to the old wikis' known stewards.

Articles

Django's Brightest Timeline

Tim Schilling argues Django's feature process has quietly come together: new-feature ideas live in a GitHub repo where emoji reactions act as votes, proposals get asked to prove themselves as third-party packages first, and Django Probe plus Praful Gulani's experimental-features GSoC work could decide what lands on usage data instead of advocacy.

Django: check version support with norwegianblue

Hugo van Kemenade's eol command pulls endoflife.date into a color-coded table, so eol django shows release, support, and end-of-life dates at a glance (6.1, 6.0, and 5.2 supported, 6.0 security-only). uv tool install norwegianblue, and it speaks Markdown, reStructuredText, and JSON for docs and scripts.

Your workers open a new Postgres connection for every task

Django's default CONN_MAX_AGE = 0 means every task a worker picks up opens its own Postgres connection, about 5ms, longer than claiming and running the task on a warm one. Set it to 600 or use a connection pool before you benchmark anything. The numbers come from django-ox's own vendor.

Automating Django deployments with Deployer

Stein Ove Helset replaces his SSH-and-run-the-commands routine with Deployer, a PHP tool that is happy to run manage.py: dep deploy builds a fresh release with its own virtualenv, runs checks, migrations, and collectstatic, then flips a current symlink and restarts Gunicorn. Shared .env and media survive between releases, and rolling back is one command.

How I decide which Python and Django versions I want to support

Matthias Kestenholz splits the question by context: projects track the current stable release or a pre-release, while the more foundational a library is, the further back it should reach. He drops versions to prune CI cost or to use something new, and lands on Python 3.10+ with Django 3.2 or 4.2+ for most packages.

Events

IndyPy: Django & FastAPI: What's Next?

Tuesday, November 24 at 7pm ET, hybrid from E-gineering in Indianapolis or over Zoom. Tim Schilling covers what's new in contributing to Django, and Calvin Hendryx-Parker argues batteries-included against speed in the Django/FastAPI debate. Register on Meetup for the in-person seat or the Zoom link.

Podcasts

Django Chat #208: Django in Space with Loes Crama

Loes Crama is a software engineer at cosine Measurement Systems, contributing to ESA's NewAthena mission. We discuss her lifelong interest in space and how her work combines software engineering, data engineering, and data science.

Videos

Django in Space with Loes Crama

Loes Crama is a software engineer at cosine Measurement Systems working on ESA's NewAthena mission, the subject of her DjangoCon Europe talk on how Django helps build the largest X-ray observatory yet. This Django Chat episode covers how she arrived at a job that combines software engineering, data engineering, and data science.

Sponsored

Reach 4,300+ Engaged Django Developers

Sponsor this newsletter to reach an active community of Python and Django developers.

Django Job Board

The PSF is hiring its next CPython Developer in Residence, alongside two senior Python roles, one AI-leaning in the US and one in Barcelona with relocation support.

CPython Developer in Residence at Python Software Foundation 🆕

Senior Software Engineer - Python, React & AI at Camden Kelly Staffing 🆕

Senior Python Engineer (Barcelona-based / Relocation support to Barcelona) at Manychat 🆕

Projects

django-ses/django-ses

A Django email backend for Amazon's Simple Email Service.

ivelum/djangoql

Advanced search language for Django admin.

Sponsor Django News

Reach 4,300+ Django developers every Friday. See sponsorship details and rates.

23 Oct 2026 3:00pm GMT

How I decide which Python and Django versions I want to support

A recent post on Mastodon got me thinking about what my philosophy for dropping support for old versions of Python and Django is. Here's the post:

🚨 Important Announcement 🚨

Going forward all my packages will only "officially" support maintained #Python versions. Meaning since October only 3.14 and now 3.15.

This has no effect on Django version support.

CVEs will be backported to older 🐍 releases.

- @codingjoe

I tend to support versions long past their End of Life date. I jokingly said that I should spend time upgrading old websites instead of spending time writing a rationale why not. I don't want to argue for my position, but maybe this post will serve as the place to point people towards when the question arises again in the future.

The short answer: it depends on whether I'm working on a project, on my own machine or on a library.

Projects

When working on projects I'm always updating to the current stable version or even the bleeding edge. I want the projects to be as future-proof as possible and I also want to give early feedback when stuff breaks.

As long as the server software allows it, I'm just going to use uv to install the newest Python version that all the packages I'm using support (or at least ship binary wheels for), because I enjoy not compiling software when deploying too damn much.

Developer workstations

When it comes to developer workstations I don't really have the patience for outdated software. I don't see a reason why developer tooling can't be up to date. This came up recently in the django-debug-toolbar issue tracker. I'm totally fine with requiring an up-to-date version of Python for our pre-commit hooks, for example.

Libraries

The more foundational and widely used a library (potentially) is, the more important it is to me that it supports basically everything which is reasonable.

I'm still using my libraries in older projects myself, so they have to work there. I want to use them in all environments, at least when I'm not paying a big price in terms of language features.

Other people may be stuck on older versions too. People can upgrade their software, but there may be situations (for example in managed hosting environments) where people cannot freely update the underlying managed server software. That isn't necessarily a problem security-wise as long as there are other measures in place protecting those services.

When people use my libraries, I might get additional eyes on the code, and possibly even contributions.

Supporting a large range of Django versions, for example 3.2 (reached EOL on 2024-04-01) up to the current main development branch, can be surprisingly easy when you do not reach too much into Django's internals or depend on features added only recently.

That said, when do I actually drop support for an old version of Python or Django? Generally speaking, I have two reasons:

🌳 Keeping CI time down 🌳

I like pruning the CI matrix so as to not spend too much compute and energy. The exceptions are packages such as django-debug-toolbar and django-tree-queries: they are widely used and have to work on a wide range of Python and Django versions and database engines, so the additional CI runs are worth it.

When I remove a version from the CI matrix I mostly raise the minimum version in the package metadata as well. I almost never use upper bounds for version ranges, but lower bounds I definitely do use.

Using new features, either because I want them or because I need them

Sometimes, I just really want to merge dictionaries using the nice a | b syntax. If this reasoning sounds whimsical to you, it is, but only partially. Programming cannot just be a job, everybody needs to have fun sometimes.

Sometimes, I really need some API or behavior Django has only introduced recently, such as the way bound fields work in forms. For example, form validation didn't go through bound fields before 4.0.

What that means right now

Most of my packages currently require Python 3.10 or newer and Django 3.2 or 4.2 or newer. Some of the less actively developed ones still go back as far as Python 3.8, simply because I haven't had a reason to touch them. Python and Django support are linked: Django 4.2 supports Python 3.8 to 3.12 while Django 6.0 requires Python 3.12, so the oldest Django version I support pretty much decides the oldest Python version worth testing.

What is the downside?

Supporting old versions makes it easier for people to put off upgrading. Some people just don't want to upgrade at all, and my libraries continuing to work on old versions certainly doesn't push them to do it. When they suddenly have to because all hell breaks loose (because of security problems or something like that) it's so much harder: they have a long way to go until they reach supported versions. That said, in my experience that's not a big problem with Django at all. On the other hand, when the projects still use npm packages from 2015… oh my.

The code is also less clean than it could be. Supporting old versions means compatibility shims, and it means not using some of the nicer features newer versions offer.

In the end, both approaches are reasonable, and both have their costs. You should do what brings you more joy.

21 Oct 2026 5:00pm GMT

🔗 Links

• Loes on LinkedIn
• cosine
• Djangocon EU: How Django is helping to build the biggest X-ray observatory to date - Loes Crama

📦 Projects

• Marimo
• django-ses
• django-anymail

📚 Books

• Weapons of Math Destruction by Cathy O'Neil
• Slouching Towards Utopia by J. Bradford DeLong

🎥 YouTube

• YouTube Channel: @djangochat

21 Oct 2026 3:00pm GMT

News

Python 3.15.0 (final) is here!

Python 3.15 is out, with explicit lazy imports (PEP 810), built-in frozendict and sentinel types, UTF-8 as the default encoding, and a JIT that runs 7-12% faster depending on the platform. If you use IDLE or tkinter on macOS 27, read the release notes first: menu dialogs can hang.

Python 3.16.0 alpha 1 is now available

The first of seven alphas for Python 3.16 is out, with features landing until the May 4, 2027 beta and the final release planned for October 5, 2027. Library maintainers are invited to start testing now.

Django Software Foundation

Django Steering Council Meetings - 2026

Notes from the October 5 meeting with the Fellows: the set-returning DEP needs reviewers, every memcached Python client is now defunct, and Python 3.15 support raises questions about makedirs permission semantics. PyPy 8.0 support and the Sovereign Tech Fund's resilience program were also on the agenda.

Wagtail CMS News

We have a stellar group of speakers for Wagtail Space 2026

The schedule is out for this year's online, half-day Wagtail Space, opening with Thibaud Colas's State of Wagtail. Talks cover running Wagtail at scale on Kubernetes, measuring a site's web emissions, agent readiness, and Wagtail Preen, a new codemod CLI.

Updates to Django

Last week we had 26 pull requests merged into Django by 9 different contributors - including a first-time contributor! Congratulations to Abheet for having their first commits merged into Django - welcome on board!

New in Django 6.2:

• The now template tag now supports passing a template variable as the format string.

New in Django 6.1:

• To improve accessibility, the admin's breadcrumbs are now rendered as <li> elements within an <ol> instead of <div> elements. The breadcrumb for the current page is now marked with aria-current="page".
• Added compatibility for oracledb 26.0.0+ (#37411).
• Fixed a regression in Django 6.1 where the YAML serializer crashed if passed the sort_keys option (#37405).
• Fixed a regression in Django 6.1 where a Value expression with a None value and an output field other than JSONField crashed on SQLite when used in a top-level JSONField in lookup (#37403). Using such an expression in an IN lookup is likely unintended, since SQL NULL cannot match any value.

Django Fellow Reports

Django Fellow Report - Jacob

Jacob cleared a spike of release blockers for 6.1.2, all but two of them found internally using a model, and added compatibility for python-oracledb 26. He also fixed a YAML serializer crash with sort_keys and landed prep work for multiline template tags.

Django Fellow Report - Sarah

Sarah shipped the October 6 security release (four CVEs plus a follow-up across three versions), the most complex she has done, and reviewed fixes like @non_atomic_requests now recognizing async views. Discussions about contributor sustainability mean Django may sit out next summer's GSoC.

Django Fellow Report - Natalia

Natalia confirmed a low-severity vulnerability and prepared its patch, filed two public hardening tickets (multipart boundaries and response header characters), and paused new HackerOne submissions. She also opened a PR to replace Django's vendored makedirs with os.makedirs() on Python 3.15+.

Sponsored

Reach 4,300+ Engaged Django Developers

Sponsor this newsletter to reach an active community of Python and Django developers.

Articles

Django: set up its test suite with uv

Adam Johnson's alternative to the official contributing setup: one uv pip install -e . -r tests/requirements/py3.txt gets Django and its test requirements into a fresh virtual environment. If pylibmc won't compile, filter it out with grep -v and process substitution, and Django skips only the memcached tests.

Towards Async Transactions in Django

Transactions need ordered queries, but async tasks interleave at every await, so one task's rollback can throw away another's writes. Carlton Gibson lays out the design worked out at the Django on the Med sprints: async with transaction.atomic() gets its own worker thread and connection, with only the opening task allowed to nest. He is aiming for 6.2, and a follow-up post says the asgiref release it depends on is due at the end of October. django-filter 26.2 is also out, adding Python 3.15 and escaping LinkWidget labels by default.

Personal Replacement for Echofeed

With Echofeed winding down, Paul Traylor built his own blog-to-Mastodon pipeline on Django's new tasks framework. His django-feedparser-low package handles feed scraping with ETag and 304 support, and a feed_filter decorator ties a task to an Entry's post_save so each feed can trigger its own processing.

Django Beginners: Part 2

Andrew Miller fleshes out his django.contrib.beginners idea as "guardrails" (stricter, silenceable warnings against common foot-guns) and "scaffolds" (starting points like the registration view django.contrib.auth leaves out), in a package meant to be outgrown. He wants to build it with a group from day one and is looking for collaborators.

Django Day Copenhagen 2026 and Secrets

Efe Oge recaps the talks that stuck with him, from Tom Carrick on rate limiting to Denny on timezones, and the hallway finding behind his own signing talk: most teams hand secret management to Ansible Vault or Kubernetes rather than Django.

Iframes that finally fit their content

Chrome 154 adds frame-sizing: content-height, so an iframe grows to fit its content with one line of CSS instead of postMessage and ResizeObserver plumbing. The catch: the embedded page has to opt in with a responsive-embedded-sizing meta tag naming the origins allowed to size it.

Core Dispatch #11

Six weeks of CPython news: Python 3.15.0 final, new PEPs for None-aware access and coalescing operators, PEP 755 withdrawn in favor of PyPI policy, the inaugural Python Packaging Council election results, and two new core developers.

Podcasts

Django Chat #207: Hiring in 2026 with Jon Gould

Jon Gould is the founder of Foxley Talent, a recruiting agency focused on Python and Django developers. We discuss what he's seeing in the market these days, the benefits of attending Python & Django conferences, and why humans matter more than ever in our new AI age.

Prefer to watch? The full episode is also on DjangoTV.

Videos

Django Day Copenhagen 2026

The October 2 livestream is now split into individual talks on DjangoTV, including keeping secrets secret in Django, timezone-safe Django, pre-commit hooks that catch Django problems early, admin model views and stand-alone pages, maintainable CRUD, and the lightning talks.

Django Job Board

Django roles were light this week, so here are two machine learning openings at HFT Architecture, one senior and one junior, that should appeal to Python and Django developers looking to branch out.

Machine Learning Engineer at HFT Architecture 🆕

Junior Machine Learning Engineer at HFT Architecture 🆕

Projects

pradeeppc/django-permission-tracer

DRF permissions end up spread across permission_classes, @action overrides, get_permissions() and composed expressions. This resolves all of it into an endpoint-to-permission map, traces which operand denied a given request, and flags endpoints an anonymous user can reach, with --fail-on-unprotected for CI.

pradeeppc/django-q-watchdog

When a django-q worker dies mid-task, the task simply vanishes: no failed row, no traceback. This records each task as it starts and heartbeats while it runs, so lost and timed-out tasks land in django-q's own Failed tasks, and a hung one gets reported as frozen.

Sponsor Django News

Reach 4,300+ Django developers every Friday. See sponsorship details and rates.

16 Oct 2026 3:00pm GMT

Django projects end up slotting into a bunch of software release cycles: Django itself, Python, database servers, cache servers, and more. It can be hard for us developers to keep track of all of them, with their different support policies and end-of-life dates, and running an unsupported version means missing out on important security or bug fixes.

norwegianblue is a handy command-line tool for checking software support dates. It fetches data from endoflife.date, a community-maintained database of release cycles for hundreds of products, and displays it as a colour-coded table. It's from Hugo van Kemenade, the Python 3.14 and 3.15 release manager, and named after the deceased parrot from Monty Python's infamous Dead Parrot sketch.

Let's look at checking the release cycles for Django, Python, PostgreSQL, and other relevant tools with it.

$ uv tool install norwegianblue

Check Django

Run the command without any arguments to see the list of product names it knows about:

$ eol
adonisjs
akeneo-pim
...

Somewhere in that long list are django and python, among others you probably care about. Run the command a product name to see its release cycles, for example:

$ eol django

Here's the output of checking Django's release cycles today, trimmed to the most recent versions:

Each row is a feature release, with LTS (long-term support) releases marked. The columns show:

• release: when the feature release came out.
• latest and latest release: the latest patch version and its release date.
• support: the end of mainstream support, after which the release only receives security fixes.
• eol: the end of extended support, after which the release receives no fixes at all.
• supportedPythonVersions: the range of Python versions that the release supports.

The dates are colour-coded: red for dates in the past, yellow for dates within the next six months, and green for dates further out. The cycle names take the colour of their eol dates, so you can quickly spot unsupported versions.

So, from the above, we can see that Django 6.1, 6.0, and 5.2 are currently supported, with 6.0 recently moving into security-fixes-only mode. Django 5.0 and 5.1 are end-of-life, so if you're still using them, it's time to upgrade! (My tool django-upgrade can help).

Check Python

You also need a supported Python version, which you can check with:

Here, support is the end of bugfix releases, and eol is the end of security releases. The pep column names the PEP containing each version's release schedule, for example PEP-790 for Python 3.15.

Python 3.10 reached its end of life recently, so it's time to upgrade any projects still using it!

Check PostgreSQL

The most popular database for Django projects is PostgreSQL, which you can check with the postgresql product name:

PostgreSQL supports each major version for five years, with no separate end of mainstream support. PostgreSQL 14 reaches its end of life next month, so it shows in yellow, as a warning to upgrade soon.

Django also drops support for old PostgreSQL versions, generally around their end-of-life dates. The Django database docs list the minimum version that each release supports.

16 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

Full title: zero-downtime multi-tenancy in Django: from user-centric to organizations-based architecture.

He works for Sendcloud. Originally their code was 2010-style Django. Every business object (Parcel, Order, etc) is linked to a django User. But... users can belong to organisations and organisations should be the ones connected to the business objects. Ok, they moved to a "core" user and "sub" users. But still users could only belong to a single organisation, for instance.

What they actually need is many users per organisation. And also many orgs per user. Roles per membership instead of per user. They designed a new system based upon this.

But: they had around 20 Django apps and 40 models with a link to user_id. How to migrate? The solution was to use a "proxy model". They started an "organisation" model that simply was a differently named Django model, pointing at the same table as the existing user model. This allowed them to keep almost everything the same with only minimal database migrations.

After that, they moved a little bit of functionality over to the new organisation model. Again, a small, minimal database migration.

They did it incrementally. They had all those apps and models to work through. Slowly but surely they got it done. Small steps that are backwards compatible help a lot.

They introduced a mistake-finder: an OrganisationAware mixin that logged direct .user access in production and produced errors in development. This helped turn up usage of the user model that wasn't findable through basic grepping and searching.

They also used libcst, an abstract syntax tree parser for python to go through the entire code and try and find corner cases where the old way of working was used.

In the end, everything was moved over to the real organisation model and the organisation-proxy wasn't needed anymore, so they could remove it. They

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Of course there's a Hohenzollern-on-a-horse statue near the Hohenzollernbridge! This one is Wilhelm II, the Kaiser during the first world war (who fled to the Netherlands, btw).

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

An asyncio event loop is defined by asyncio.AbstractEventLoop. That's a large API with more than 50 public methods, but only three are fundamental. At the lowest useful leve, the loop manages callbacks, i/o and timers.

• We need a way to put events on a queue and a way to grab events from a queue and execute them. call_soon()
• We need timers too, for callbacks that must be run after some time. call_later()
• Sleep only knows about time. Often we want to sleep until the next time, unless a socket becomes ready first. So we need a "sleep" that can be interrupted by I/O readiness. add_reader(), add_writer()

His own example implementation of asyncio for educational purposes is at: https://github.com/tarasko/eduloop , it is only 250 lines. Handy if you want to understand asyncio.

He showed this simple example code, incrementally implementing the points above.

The nice thing about asyncio is coroutines. A coroutine is an extended kind of function that can be paused and resumed. The result is a "future". A future represents an eventual result of an async operation. So: a future is pending until somebody supplies either a result or an exception.

For network connection there's Transport and Protocol.

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. St. Gereon church.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

First some terminology. Cohesion and coupling for instance.

• Cohesion means how much the elements in a module belong together. "Belonging together": working towards the same goal or function. Watch out what your answer is: is there an "and" in the sentence. "This module reads data and puts it in the database". That's a sign of lower cohesion.

  Cohesion also has to do with your mental load: what can you keep in your head at the same time?

• Coupling. Basically the blast radius: how much breaks when you change an object.

• Change. Not often talked about. Architecture is more than diagrams. Architecture actually is making future changes cheaper. No change, no pain.

Loose coupling, high cohesion is good. Tightly coupled, low cohesion is bad.

Python allows us lots of freedom. There is no enforcement of architectural boundaries. You have type hints, but they're not enforced. Python's basic assumption is that we're all reasonable and responsible programmers.

Let's look at an example problem. We have "the internet" that calls "our REST API" that stores stuff in "our database". We start with a single function in our API that queries the database and returns the results. But then we want to uncouple the data and the presentation layer: some ORM around the database table that is called by the view function (=the original API function). All fine. But... when the database changes, the ORM layer changes and then the view function needs to change. Coupling, anyone?

How can we fix this? By having some sort of contract between the layers. A domain model in between. A change in the database means a change in the part of the code that creates the domain object, but the view function is unaffected.

But such a view function often also contains business logic. That often means you're doing some talking to the database anyway. A normal approach is to put that part of the code into some "service" layer. You can also start writing adapters: convert the core domain models to some output format.

Closing remarks:

• Your business rules deserve a home!
• Put them somewhere the outside world can't hurt them.

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Organ in the St. Aposteln church.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

Full title: stop firefighting: practical observability for Python APIs, workers & jobs. The most important points:

• What does it mean for a system to be observable?
• Does that answer look the same for an API, a worker and a job?
• Metrics tell us something is wrong, but how do we find out what happened and where?
• How do we get the system to tell us, before our users do?
• Where do we actually start without doing everything at once?

They started with a prototype of a new system. They had questions like "does it work" and "is it fast enough". So they added a bit of monitoring: just a couple of logs and some simple graphs. And pushed it to production right away...

What does "observable" mean? It means you can answer questions like: is it up? Is it ready to serve traffic? Is it doing useful work? Is it failing? Is it slow? What changed recently? Which dependency/workload/customer/job/event-type is involved?

Is the answer the same for everything? No. You can have an API that restarts just fine on an error. So: it is up again, no problem. But because of the restart, it might have gotten a new IP address that isn't recognised by something else in your stack. So the API works, but the rest of the app doesn't. (That's a real case that they saw.) Or a nightly database import job might succeed just fine (but there's no new data as an upstream pipeline failed).

Metrics can help you notice problems before they become critical. Like API response times that slowly creep upwards. Time to investigate! Or something really goes wrong and the number of "error 500" messages spikes. Then you have to move from your metrics to the logs. There you can hopefully see what went wrong. If you need to dive deeper, you can start to use tracing (she doesn't recommend activating this right away).

Notifications. There's a sliding scale between "no observability" (the user has to report errors) and "alert on everything" (leading to alert fatigue). She recommends starting with a low number of alerts and slowly working upwards from there.

How to start? Best approach: roll it out in phases.

• Start with basic visibility: health/readiness, structured logging.
• Then workload metrics: request rate, error rate, number of processed jobs.
• Then high-confidence alerts: api not ready and so. "P99" latency. Job queue backlog without progress.
• Then dashboards.
• And last tracing and deeper instrumentation.

She wrote an article about it: part one.

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Hohenzollern railway bridge plus kathedral.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

Full title: fire, forget, regret: building resumable Python pipelines.

If you run a task in an async loop, there's often no reference to the task. So it can be garbage collected! You can solve that by keeping a reference in some list. But even then, the whole process can die. What happens with your task then?

Often you have to re-run the task. He himself is into LLMs, so failed tasks that you have to re-run can become expensive.

BackgroundTasks is part of FastAPI and it works great for spinning off longer running tasks. Real handy, but there is no retry mechanism and no recoverability in case of crashes. "Fire-and-forget".

You can use specific task queues. ARQ, Celery, Dramatiq. In this case, the job itself is safe and can be re-tried. But not the individual steps within the job.

What he wants is durable execution. Write down every step you finish; on restart, skip what is written. It can save you lots of time (and possibly money). It might be simpler to set up than you think.

His code + slides are at https://github.com/batman004/fire-forget-regret

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Model of the oldest parts of the St. Gereon church.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

Why Python for 3D? It often used to be done in C++. He showed an example in C++ and Python: the Python example was much shorter. But: Python is often only the interface, behind the scenes the library you use is often written in C/C++/Rust/etc.

The library landscape. There are many libraries you can use. Loading and storing: laspy, pdal, pyproj. Arays and speed; numpy, scipy, numba, dask. Processing: open3d, trimesh. Visualisation: pyvista, vtk. Learning: scikit-learn, pytorch3d.

One real pipeline. He used a pointcloud of part of the Jaarbeurs complex (where the conference was taking place), sourced from the Dutch public https://ahn.nl data source. The density is about 18 points per square meter and it uses some Dutch coordinate system ("RD New").

A point cloud is just a set of points in 3D space. You can also represent it as a mesh (3d areas). A "voxel grid" is also often handy: you convert what you're seeing into small stacked cubes.

What you need to do in a project: acquisition, preparation, exploration, analysis, visualisation.

No single library does the whole job. A partial exception is numpy: every step uses numpy vectors internally. He loaded the data with "laspy". Then voxel downsampling with open3d (he took the average of all points in a cubic meter). 700k points turned into 200k points this way: much more manageable. He then did a bit of clustering and colored the clusters by data from a land use database.

Making it fast. Using numpy's array operations is key. Don't iterate over a loop in Python, but let numpy do its work. That way, there's highly optimised compiled C++ code doing the work.

Some takeaways. Think in arrays, not points. Look befor you compute (so: check your data for obvious errors or problems). Make it small first. Let compiled code do the work.

His presentation is at https://github.com/Sloppy1999/pycon-nl-2026-3d-data-science

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Railway tracks ('linksrheinische') behind the hotel, at the site of the former 'Köln Gereon' goods yard.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

This year is the first community-organized Pycon NL: hurray!

Most of us use open source as users. It is free! But all those open source projects only exist because someone started it and because someone maintains it.

"Care became contagious": she told the story about someone in Mumbay, India that started to clean up plastic waste that covered the whole beach. He and a 84 year old neighbor. Slowly other people joined in. Then a lot more. Care became contagious!

Python started when Guido van Rossum made a new language in his Christmas holiday.

But projects like this are fragile. The beach cleanup (almost?) stopped after 109 weeks: administrative lethargy, heckling, etc. (She said it stopped, but I guess it almost stopped, as later on she had photos of a clean beach with newly-hatched turtles). If you start a nice open source project, you're probably not thinking my dream is to answer Github issues for the next 20 years.

Sustainability is not endurance. Sustainability is regeneration. Joining a community, but also having the option to leave (just as an example).

Open source is safe. In open source project, code is public, knowledge is shared. A community. The community is the infrastructure. The community is the reason the code is trustworthy.

The Python software foundation holds the trademarks and licenses. Infrastructure like python.org, pypi, the documentation website. It hosts/helps conferences.

Pypi, the Python package index. 81.000 requests per second. And there are only two full-time security people working on it. Seth Larson and Mike Fiedler. We can call them heroes, but we might also look at Python's growth compared to the growth of its human infrastucture.

Our human infrastructure hasn't grown with Python's growth. And AI is making it more urgent. AI can consume whatever the community has to offer or has ever offered. Without giving something back. AI companies capture our value...

Public spaces are not self-maintaining. They need funding and public responsibility.

In 2025, the United Nations published the UN Open Source Principles. Countries are taking note. For example, Germany has the Sovereign Tech Fund, that invests directly in the people behind the code, supporting maintainers, community managers and technical writers.

She started Open community Leadership, helping communities create future contributors and leaders. The foundation is POPCOM: participation (how to join), ownership (how to gain responsibility), purpose (why people stay), connection (how relationships form), opportunity (how contributors grow), mentorship (how communities reproduce).

Regeneration takes people, time and money.

Open source is better together.

Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Extreme low water in the Rhine: the 'beach' on the left should be fully submerged.

15 Oct 2026 4:00am GMT

(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).

Routes: not every route starts the way people think. Here's his route through life.

You might know Marcelo from uvicorn, fastapi, starlette, logfire, Pydantic AI, MCP Python SDK, httpx2... It started for him in 2017 when he played league of legends for a full semester and failed all courses. This closed his main route: graduating on time and getting the expected job. Instead he got a good-enough job somewhere in Florianópolis (Brazil).

What was your closed route? It might be a degree you didn't finish. A field that changed under you. A job you didn't get. A move.

One thing he wants to talk about: curiosity needs a direction. You might be curious, but where does it get you? You might have a direction (like a degree plus the expected job), but direction alone, what does it get you? But if you have both curiosity and direction: that's nice.

Marcelo was curious in open source. What helped him a lot was to get involved. With open source you can look at issues and start fixing them and slowly getting more and more involved.

In 2020, the web question in python was "Django or Flask". He picked the third option: FastAPI, and started using it for his job. That resulted in bug reports or feature requests from colleagues that he then could fix in FastAPI itself. He even took over maintainership of python-multipart: by asking the not-really-active-anymore maintainer. Marcelo got the maintainership because he was already known in the community through his other open source work.

Asking can chance your path, just like with the maintainership of python-multipart. Likewise, he asked for a job at Pydantic though his open source contacts. And got it! He works for Pydantic ever since.

What can you open if you want to change your route? What can you do? Is it too late to:

• Start contributing to open source?
• Learn a new language?
• Pick up a hobby?
• Change careers?

According to Marcelo, it is never too late. One thing he'd focus on is fun. Have fun with open source, for instance, in his case. It almost started out as his hobby. And he likes AI right now. One of the things he's having fun with right now is zttp, an IO-less HTTP parser for Python with a Zig core. He mentioned that AI helped him experiment. Another project is pgtask, a Postgresql-native durable task queue + workflow engine.

A big part of his personal workflow is to look at his github notifications for all his projects. Just look at one notification (and thus one issue or PR) at the time and to bring it a little step forward, one at a time.

Normally he handled between 300 and 700 pull requests per year. This year it is already above 2500 (due to AI). Like many maintainers, the workload has gone up. He noticed he actually made noticeably fewer releases this year, though.

Maintainance is a form of care. Care and feeding for your projects. Triaging issues, reviewing PRs, saying "no", closing the noise. You're a maintainer, too. Anything that only works because someone shows up. It might be your own life, your family, your club, your project.

Marcelo once got the tip to grow on three tracks at once. Don't ignore any one of them, you need them all:

• Professionally: grow in your job.
• Personally: family, relationships, friends.
• Healthily: exercise and nutrition. Body and mind.

You might notice that one of those three tracks is starting to eat the others. You can't remember the last day without a laptop, for instance. Or you spend a year at home on open source and tell yourself it's fine.

He made a comment about AI. He works on AI tools every day. He still doesn't know where it goes. He knows some of the routes might be closing for you because of AI. As a maintainer, he actually uses AI. He lets AI review pull requests, he lets it write his one pull reuqets. Security advisories. But AI doesn't diminish his enthousiasm and curiosity.

Remember the bring it a little step forward, one at a time he mentioned before? Your route will be different from Marcelo's. But the only thing you need to get further along on your own route is to move a little step forward every time.

Unrelated photo from our `Nelen&Schuurmans <https://www.nelen-schuurmans.nl>`_ company trip to Cologne/Köln in Germany. The salad I had for lunch on Saturday was tasty.

15 Oct 2026 4:00am GMT