12 Aug 2026
Planet Python
Python Bytes: #491 Feeling Judged
<strong>Topics covered in this episode:</strong><br> <ul> <li><strong>Claude Code /insights</strong></li> <li><strong><a href="https://blog.trailofbits.com/2026/06/30/shipping-post-quantum-cryptography-to-python/?featured_on=pythonbytes">Post-quantum crypto lands in Python</a></strong></li> <li><strong><a href="https://realpython.com/python-news-august-2026/?featured_on=pythonbytes">MCP goes stateless - and FastMCP gets renamed</a></strong></li> <li><strong><a href="https://github.com/microsoft/inshellisense?featured_on=pythonbytes">inshellisense - IDE style command line auto complete</a></strong></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=5iaT_bO3INA' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="491">Watch on YouTube</a><br> <p><strong>About the show</strong></p> <p><strong>Sponsored by</strong> <a href="https://pythonbytes.fm/xweather">Xweather</a> Xweather combines enterprise-grade weather intelligence with agent-ready APIs, natural language capabilities, and an MCP server so your agents can adapt workflows, automate responses, and make better decisions based on real-world conditions. Michael will tell you more about them later in the show. Get started for free at <a href="http://pythonbytes.fm/xweather">pythonbytes.fm/xweather</a> <strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy">Mastodon</a> / <a href="https://bsky.app/profile/mkennedy.codes?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/mkennedy?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/mkennedy/?featured_on=pythonbytes">LinkedIn</a></li> <li>Calvin: <a href="https://sixfeetup.social/@calvin?featured_on=pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/calvinhp.com?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/calvinhp?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/calvinhp/?featured_on=pythonbytes">LinkedIn</a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/pythonbytes.fm">BlueSky</a> / <a href="https://x.com/PythonBytes?featured_on=pythonbytes">X</a> Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/live</strong></a> to be part of the audience. Usually <strong>Tuesday at 7am PT</strong>. Older video versions available there too. Finally, if you want an artisanal digest of every week of the show notes in email form? Add your name and email to <a href="https://pythonbytes.fm/friends-of-the-show">our friends of the show list</a>, we'll never share it.</li> </ul> <p><strong>Michael #1: Claude Code /insights</strong></p> <ul> <li>Michael's Insights: <a href="https://blobs.pythonbytes.fm/michael-kennedy-claude-code-insights-2026-08-09.html?cache_id=6c6ef5">michael-kennedy-claude-code-insights-2026-08-09.html</a></li> <li>Be careful sharing these outputs, they include details references to your projects, errors, security findings, etc. ;)</li> <li><code>/insights</code> reads your last 30 days of local session transcripts and hands back an interactive HTML report on how you actually work. <ul> <li><strong>One command, zero setup</strong>: type <code>/insights</code> in a session, or run <code>claude -p "/insights"</code> from the shell for a non-interactive version that just prints the path</li> <li><strong>Reads what's already on disk</strong>: pulls session logs from <code>~/.claude/projects/</code>, skipping agent sub-sessions and anything under 2 messages or 1 minute</li> <li><strong>Project areas</strong>: clusters your sessions into themes like "CLI Tooling" or "Documentation" with session counts</li> <li><strong>Friction analysis</strong>: categorizes where things went wrong by root cause - and quotes your own prompts back at you</li> <li><strong>Interaction style</strong>: tells you whether you're a delegator or a micromanager, plus which workflows are worth doubling down on</li> <li><strong>Actually actionable</strong>: suggests concrete <a href="http://CLAUDE.md?featured_on=pythonbytes">CLAUDE.md</a> additions and Claude Code features you're not using</li> <li><strong>The catch</strong>: Haiku does the per-session classification, so the first run takes several minutes; results cache to <code>~/.claude/usage-data/facets/</code> and the report lands at <code>~/.claude/usage-data/report.html</code></li> </ul></li> </ul> <p><strong>Calvin #2: <a href="https://blog.trailofbits.com/2026/06/30/shipping-post-quantum-cryptography-to-python/?featured_on=pythonbytes">Post-quantum crypto lands in Python</a></strong></p> <ul> <li><code>pyca/cryptography</code> 48 ships ML-KEM (key establishment) and ML-DSA (signatures) - NIST's post-quantum standards, now one <code>pip install</code> away.</li> <li>Big deal because it's the 11th most-downloaded package on PyPI (~1.2B downloads/month) and sits under Ansible, Certbot, Airflow, and paramiko. No PQ there, no PQ anywhere in Python.</li> <li>Trail of Bits did the work (Rust bindings, cross-backend API, tests, AWS-LC backend support), funded by the Sovereign Tech Agency.</li> <li>Timing tracks a June 22 White House order setting federal deadlines: PQ key establishment by end of 2030, PQ signatures by end of 2031.</li> <li>Not a drop-in swap - the wire sizes explode. ML-DSA-65 signatures are 3,309 bytes vs Ed25519's 64; ML-KEM-768 public keys are 1,184 bytes vs X25519's 32. Hardcoded field sizes and length prefixes will bite.</li> <li>API looks like the existing asymmetric primitives, except ML-KEM is encapsulate/decapsulate rather than a Diffie-Hellman exchange. SLH-DSA (the hash-based conservative backstop) is still in progress. The primitives are here, but protocols haven't caught up - so you won't be running post-quantum Certbot this week.</li> </ul> <p><strong>Sponsor: Xweather</strong></p> <p>You're using agents that can write code, summarize documents, and automate workflows. But they're missing one thing: awareness of the world around them. This is where today's sponsor, Xweather comes in. Xweather combines enterprise-grade weather intelligence with agent-ready APIs, natural language capabilities, and an MCP server built for tools like Claude, Codex, Copilot, and modern IDEs - so your agents can adapt workflows, automate responses, and make better decisions based on real-world conditions. Backed by Vaisala, whose instruments fly on NASA missions to Mars, Xweather delivers trusted data and unique insights that go beyond conditions to actual impact - from real-time lightning strikes to road surface forecasts. Start with 15,000 free API calls each month and pay only for what you use as you grow. Xweather is your full weather stack, for developers by developers. Start building for free today at <a href="http://pythonbytes.fm/xweather">pythonbytes.fm/xweather</a>. The link is in your podcast player's show notes and on the episode page. Thanks so much to Xweather for supporting Python Bytes.</p> <p><strong>Calvin #3: <a href="https://realpython.com/python-news-august-2026/?featured_on=pythonbytes">MCP goes stateless - and FastMCP gets renamed</a></strong></p> <ul> <li>From <strong>Philipp Acsany</strong> over at Real Python</li> <li>The <code>2026-07-28</code> spec landed July 28 and the Python SDK shipped 2.0.0 the same day. Biggest rewrite since MCP launched, and it's breaking on purpose. Context for scale: the Tier 1 SDKs are pulling close to half a billion downloads a month, with TypeScript and Python each past a billion total.</li> <li>The headline is the stateless core. The <code>initialize</code>/<code>initialized</code> handshake and the <code>Mcp-Session-Id</code> header are both retired - protocol version, client identity, and capabilities now ride in <code>_meta</code> on every request, with an optional <code>server/discover</code> RPC if a client wants capabilities up front. Any request can land on any instance behind plain round-robin, no shared storage.</li> <li>Server-initiated calls are the hard part of the migration. Sampling, elicitation, and <code>roots/list</code> no longer call back to the client; instead the server returns <code>resultType: "input_required"</code> and the client retries with <code>inputResponses</code> attached. Multi Round-Trip Requests, MRTR. Also: <code>Mcp-Method</code> and <code>Mcp-Name</code> are now required headers so gateways route on headers instead of cracking JSON bodies, and missing-resource errors move to standard <code>32602</code>.</li> <li>Deprecation sweep with an actual policy behind it - Roots, Sampling, Logging, and the legacy HTTP+SSE transport all deprecated with a twelve-month minimum offramp. Tasks graduated out of the experimental core into a real extension, which is what the formalized extensions framework was for. MCP Apps is now an official extension too, so a tool call can return sandboxed interactive HTML. Auth picked up RFC 9207 issuer validation, issuer-bound credentials, and a shift from DCR toward CIMD.</li> <li>Python SDK 2.0 is where it gets personal: <code>FastMCP</code> is now <code>MCPServer</code>, no alias, no shim. <code>McpError</code> → <code>MCPError</code>. Wire types went snake_case (<code>is_error</code>, <code>input_schema</code>) and moved to a standalone <code>mcp_types</code> package, with <code>mcp.types</code> kept as a permanent alias. One <code>Client</code> object replaces the old transport + <code>ClientSession</code> + <code>initialize()</code> stack. <code>httpx</code> became <code>httpx2</code>. Sync handlers run on worker threads now, so <code>asyncio.get_running_loop()</code> raises inside them.</li> <li>The good news: one <code>MCPServer</code> serves both protocol eras, so 2025-era clients keep working with nothing to configure, and a <code>Resolve(fn)</code> parameter lets one tool body cover MRTR and the old path. 1.x is maintenance-and-security-fixes only - pin <code>mcp>=1.28,<2</code> if this week is already full. The Tasks extension isn't in 2.0.0 yet, so Tasks has left the core spec but hasn't landed in the SDK. If you only <em>call</em> MCP servers, you mostly just get the benefits for free. If you <em>ship</em> one, you already know what your week looks like. And if you use the standalone <code>fastmcp</code> package instead of the official SDK - different project, 3.x line, none of this touches you. The rename is partly to stop the two from being confused.</li> </ul> <p><strong>Michael #4: <a href="https://github.com/microsoft/inshellisense?featured_on=pythonbytes">inshellisense - IDE style command line auto complete</a></strong></p> <ul> <li>via Doug Nichols</li> <li><code>inshellisense</code> provides IDE style autocomplete for shells.</li> <li>It's a terminal native runtime for <a href="https://github.com/withfig/autocomplete?featured_on=pythonbytes">autocomplete</a> which has support for 600+ command line tools.</li> <li><code>inshellisense</code> supports Windows, Linux, & macOS.</li> <li>If you are using a <a href="https://www.nerdfonts.com/?featured_on=pythonbytes">NerdFont</a> patched font, you can enable the NerdFonts support in your config file</li> </ul> <p><strong>Extras</strong></p> <p>Calvin:</p> <ul> <li>Django 6.1 Released - https://www.djangoproject.com/weblog/2026/aug/05/django-61-released/</li> <li>DjangoCon US is quickly arriving, grab your tickets now! - https://2026.djangocon.us/ Michael:</li> <li><a href="https://pythonbytes.fm/ai-integration">AI integration: Python Bytes for AI</a></li> <li><a href="https://training.talkpython.fm/courses/up-and-running-with-rust?featured_on=pythonbytes">Up and Running with Rust Course is out!</a></li> </ul> <p><strong>Joke: <a href="https://programmerhumor.io/security-memes/google-p5hl?featured_on=pythonbytes">But they already know</a></strong></p>
12 Aug 2026 1:00am GMT
11 Aug 2026
Planet Python
TestDriven.io: Storing Django Static and Media Files on Cloudflare R2
This tutorial shows how to configure Django to load and serve up static and media files, public and private, via Cloudflare R2.
11 Aug 2026 10:28pm GMT
PyCoder’s Weekly: Issue #747: Modern OOP, bisect, Django Async, and More (2026-08-11)
#747 - AUGUST 11, 2026
View in Browser »
New Book: Modern Object-Oriented Python
Real Python's new book on classes, Python's data model, and object-oriented design is out in Early Access. Nine chapters collected from a decade of tutorials, re-edited into one curriculum, and updated for today's Python.
REAL PYTHON
Binary Search in Python With bisect
Python's bisect module implements binary search for you. Here's how bisect_left, bisect_right, and insort work, plus recipes for finding the closest match or all values in a range.
TREY HUNNER
Let AI Agents Into Your B2B App. Securely
More of your users are asking to connect AI agents to your product, and you want to say yes. PropelAuth lets you give each agent scoped, revocable access, so you stay in control of what it can do. Learn More →
PROPELAUTH sponsor
Updates on Django's Async Story
For years, "Django and async" came with an asterisk. The docs themselves warned you off it, but that has changed. Talk Python interviews Carlton Gibson and they talk async in Django.
TALK PYTHON
Articles & Tutorials
Take the 2026 Python Typing Survey
Now in its third year, the Python Typing Survey has become a recognised reference point for the direction of Python's type system. It's being referenced in PEPs and presentations to the Python community. Whether you're an experienced user of Python types or someone who hasn't yet written your first type annotation, participating in this survey helps the open-source community make Python better for everyone.
SURVEYMONKEY.COM • Shared by Abby Mitchell
Hydra for Python Configuration: Build Modular and Maintainable Pipelines
Hardcoded paths and parameters can quickly drift out of sync across a data science project's scripts. This article shows how to move them into Hydra configuration files, access values with dot notation, override settings from the command line, swap entire configuration groups, and run experiment sweeps with a single multirun flag.
CODECUT.AI • Shared by Khuyen Tran
📘 Modern Object-Oriented Python: Write Clean, Pythonic Code With OOP
Learn to design classes that feel native to Python: special methods, inheritance vs. composition, properties, data classes, and the SOLID principles. Get Your Copy →
REAL PYTHON sponsor
asyncio.all_tasks() Could Silently Drop Tasks on the Free-Threaded Build
A concrete example of how free-threading turns old GIL-era assumptions into silent bugs: asyncio.all_tasks() dropping live tasks from another thread. Useful for anyone porting or debugging code under the free-threaded build. Written by the author of the fix.
DEADLOVELLL.GITHUB.IO • Shared by Timofei Ivankov
Celery: From First Task to Advanced Recipes
Celery is a mature distributed task queue for Python, but many practical details aren't immediately obvious from the documentation. This guide goes from the basic usage to timeouts, retries, preventing parallel execution, and emulating async/await support.
STANISLAV GOLEV • Shared by Stanislav Golev
Programmatically Developing LLM Prompts With DSPy
How can you move from manually writing prompts for an LLM application toward defining them programmatically? This week on the show, Brett Kennedy returns to discuss his new book "Building LLM Applications with DSPy."
REAL PYTHON podcast
Nifty Django Feature: setUpTestData
The setUp() call in TestCase gets invoked for every single test. Django adds setUpTestData() which only gets called once per test class, meaning your tests can run faster.
TIM SCHILLING
Thoughts on "SIMD in Pure Python"
This article is a response to SIMD in Pure Python and discusses ways of optimizing his code even further.
ALISA SIRENEVA
Since When? Which Python Version Added That
An interesting tool where you paste Python into it to see which version added each feature it uses, or look up a single built-in, module, or piece of syntax.
PYTHONMORSELS.COM
Validating Data With Pointblank in Python
Learn how to validate data in Python with Pointblank: declare quality checks, split clean from failing rows, and rerun validation plans from YAML.
REAL PYTHON
Acidica
Ned has written a toy BASIC interpreter in Python. This announcement post tells you why ("for fun") and talks about the accomplishment.
NED BATCHELDER
Some More Things About Django I've Been Enjoying
Julia has been learning Django to create websites in "2010 style". This post talks about new things she's picked up along the way.
JULIA EVANS
Sending Emails Using Python
Learn how to send emails with Python using SMTP and smtplib, attach files, format HTML messages, and personalize bulk emails.
REAL PYTHON course
Projects & Code
Events
Weekly Real Python Office Hours Q&A (Virtual)
August 12, 2026
REALPYTHON.COM
Python Nordeste 2026 (PyNE 2026)
August 13 to August 16, 2026
PYTHONNORDESTE.ORG
Python Help: Problems to Solutions
August 13, 2026
NONE
Python Atlanta
August 13 to August 14, 2026
MEETUP.COM
PyCon Korea 2026
August 15 to August 18, 2026
PYCON.KR
DjangoCologne
August 18, 2026
MEETUP.COM
PyCon Ghana 2026
August 20 to August 23, 2026
PYCON.ORG
PyCon Latam 2026
August 20 to August 24, 2026
PYLATAM.ORG
PyCon JP 2026
August 21 to August 24, 2026
PYCON.JP
Happy Pythoning!
This was PyCoder's Weekly Issue #747.
View in Browser »
[ Subscribe to 🐍 PyCoder's Weekly 💌 - Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]
11 Aug 2026 7:30pm GMT
Django community aggregator: Community blog posts
Duff's device in JavaScript
In 1983, Tom Duff needed to copy memory into an output register faster than his compiler could manage, and wrote the most famous abuse of switch in the history of C. I ported his device to JavaScript and raced it against the plainest possible loop - and the verdict changed with the engine, the engine's version, and the CPU underneath.

11 Aug 2026 10:00am GMT
08 Aug 2026
Django community aggregator: Community blog posts
Django: introducing django-msgspec
It's another day, another new package day here. Say hello to django-msgspec, a package of drop-in replacements for Django and Django REST Framework (DRF) components backed by msgspec.
msgspec is a C-based serialization library covering JSON, MessagePack, YAML, and TOML, with optional schema validation through typed Struct classes. Its JSON encoder and decoder are several times faster than the standard library's, which makes django-msgspec a cheap performance win in the parts of Django that handle JSON.
Features
There's a version of JsonResponse:
from django_msgspec.http import JsonResponse
def index(request):
return JsonResponse({"title": "Hello, world!"})
…a test client with matching test case classes:
from django_msgspec.test import SimpleTestCase
class IndexTests(SimpleTestCase):
def test_index(self):
response = self.client.get("/", headers={"accept": "application/json"})
assert response.status_code == 200
# response.json() uses msgspec to parse the response body
assert response.json() == {"title": "Hello, world!"}
…a version of Django's json_script template tag, which is where this whole story began:
{% load django_msgspec %}
{{ sales_by_product_id|json_script:"chart-data" }}
…and a handful of components that you activate purely through settings, with no code changes at all:
SESSION_SERIALIZER = "django_msgspec.sessions.JSONSerializer"
SERIALIZATION_MODULES = {
"json": "django_msgspec.serializers.json",
"jsonl": "django_msgspec.serializers.jsonl",
}
REST_FRAMEWORK = {
"DEFAULT_RENDERER_CLASSES": ["django_msgspec.rest_framework.JSONRenderer"],
"DEFAULT_PARSER_CLASSES": ["django_msgspec.rest_framework.JSONParser"],
}
That covers session storage and signing, dumpdata / loaddata in both JSON and JSON Lines, and DRF request parsing and response rendering.
Everything encodes with an enc_hook that knows about Django's lazy strings, so translated text passes through as you'd expect. It's all tested against the currently supported versions of Python and Django, with 100% coverage.
Déjà vu?
Only three weeks ago, I introduced django-orjson, a near-identical package backed by the Rust-powered orjson. So yeah, you might be confused why I made another faster-alternative-JSON-package-wrapper package so soon after the first one.
After releasing django-orjson, several folks from the community reached out to me telling me about the issues with orjson and pointing to msgspec instead. Additionally, while trying to roll out django-orjson on a client project, I learned that certain documented behaviours and limitations in orjson were going to be road blockers.
Here's a full list of what I learned:
-
Dictionary keys have to be strings. Take a mapping of object ID to some count:
>>> import json >>> json.dumps({1: "one"}) '{"1": "one"}' >>> import orjson >>> orjson.dumps({1: "one"}) Traceback (most recent call last): ... TypeError: Dict key must be str
JSON objects can only have string keys, so the standard library coerces non-string keys with
str(). But orjson refuses to do so, with the justification that the coercion is lossy and the keys will come back as strings when deserialized. Thankfully orjson does have an option here,OPT_NON_STR_KEYS, that opts in to the standard library behaviour, but you gotta know about it! -
Integers are limited to 64 bits.
>>> json.dumps(2**64) '18446744073709551616' >>> orjson.dumps(2**64) Traceback (most recent call last): ... TypeError: Integer exceeds 64-bit range
JSON itself sets no limit on number sizes, but RFC 8259 warns that implementations may, and many do-JavaScript, for one, silently loses precision beyond 253. orjson caps integers at 64 bits, matching native integer types, while Python's arbitrary-precision integers mean the standard library will happily emit larger values.
In this case, orjson is probably more correct, but it is lacking an option to restore compatibility if required. (I didn't encounter any use case for massive numbers myself.)
-
There's nowhere to report problems.
The orjson README sayeth:
There is no open issue tracker or pull requests due to signal-to-noise ratio.
I have plenty of sympathy for that decision, having felt the weight of my own project's issue trackers backing up. But it does mean that when you hit any problems, you can't check whether it's known, follow a fix, or contribute one. Your options are to read the CHANGELOG and hope, or to work around it yourself.
-
No sub-interpreter support, ever.
The README also says:
orjson does not and will not support PyPy, embedded Python builds for Android/iOS, or PEP 554 subinterpreters.
I kinda missed this one when adopting orjson, but for me it's a bit of a concern. I think subinterpreters could support some cool use cases, like fast parallel test runners, and from my experience writing extension packages, support for them does not add much overhead.
And this is not a soft limitation-you can't even import orjson in a sub-interpreter, let alone serialize anything:
>>> from concurrent import interpreters >>> interp = interpreters.create() >>> interp.exec("import orjson") Traceback (most recent call last): ... concurrent.interpreters.ExecutionFailed: ImportError: module orjson.orjson does not support loading in subinterpreters
It's a shame that the orjson maintainer advertises such a hard line here.
-
No free-threading support yet.
orjson currently publishes no wheels for free-threaded Python, which is now "stable" as of Python 3.14. On a free-threaded build, you're forced to compile the Rust package from source, which is a bit of an adoption blocker for large teams.
-
Pydantic decided against it, on trust grounds.
Back in 2019, a contributor opened a pull request to use orjson in Pydantic, and Samuel Colvin declined it. His stated reasons were:
- orjson's author gives no name or personal details on GitHub.
- The author had privately emailed Sam asking for the integration, and he was "surprised and somewhat worried by the hostile response I got when I made his/her request public".
- The compiled wheels for the package could potentially contain malicious code, which seems like more of a risk given the author's anonymity.
He was careful to add: "Let me make it clear: I'm not accusing <the maintainer> of anything, I'm 99% certain that his/her intentions are honourable."
I have the same feelings, now that I'm aware of all the (public) details of orjson. Pseudonymity is entirely legitimate and plenty of excellent software is written under a handle, and this was seven years ago. But stack it up with the closed issue tracker, and it does mean that installing orjson means trusting a compiled binary from a maintainer who has chosen not to engage in public at all.
msgspec's advantages
msgspec answers the questions raised by the above points against orjson:
-
It handles numerical keys the way the standard library does:
>>> import msgspec.json >>> msgspec.json.encode({1: "one"}) b'{"1":"one"}'
-
It encodes and decodes large integers:
>>> import msgspec.json >>> msgspec.json.encode(2**64) b'18446744073709551616' >>> msgspec.json.decode(b"18446744073709551616") 18446744073709551616
-
It has an open issue tracker.
-
msgspec fails to import in sub-interpreters right now, but the issue is being worked on by the maintainer and contributors.
-
msgspec publishes free-threading compatible wheels today.
-
The creator is not anonymous and the project is now maintained by a group in a GitHub organization, featuring at least Nikita Sobolev who I have known online from other open source projects (especially django-stubs).
And most importantly, msgspec's encoding and decoding are in the same performance ballpark as orjson's!
msgspec has standard library incompatibilities too
By the way, msgspec isn't fully compatible with json-here are the differences that I know about.
- Non-finite floats are encoded as
nullrather than the standard library'sNaNandInfinity:
>>> json.dumps(float("inf")) 'Infinity' >>> msgspec.json.encode(float("inf")) b'null'I'd call this an improvement, since
Infinityisn't valid JSON and other parsers will reject it. But it is a change, so if you rely on round-tripping those values, take note.
- msgspec also only coerces keys that are string-like or number-like, so booleans and
Noneare still rejected:
>>> json.dumps({None: "nothing"}) '{"null": "nothing"}' >>> msgspec.json.encode({None: "nothing"}) Traceback (most recent call last): ... TypeError: Only dicts with str-like or number-like keys are supportedSuch keys should be rarer than numbers in practice.
What might come next in django-msgspec
django-msgspec covers the same ground as django-orjson today, but msgspec is a broader library than orjson, so there's more potential for future development.
First, msgspec's typed container class, Struct, lets you decode and validate in a single pass:
>>> import msgspec
>>> class Sale(msgspec.Struct):
... product_id: int
... count: int
...
>>> msgspec.json.decode(b'{"product_id": 1, "count": 2}', type=Sale)
Sale(product_id=1, count=2)
>>> msgspec.json.decode(b'{"product_id": "one", "count": 2}', type=Sale)
Traceback (most recent call last):
...
msgspec.ValidationError: Expected `int`, got `str` - at `$.product_id`
This could be useful for combining with Django views, DRF parsers, or even forms.
Second, msgspec can serialize and deserialize other data types, so they might be worth integrating.
Happy to take suggestions on the design here, on the issue tracker.
Fin
Please try out django-msgspec today and let me know how it goes.
May all your messages be to specification,
-Adam
08 Aug 2026 2:24am GMT
07 Aug 2026
Django community aggregator: Community blog posts
Issue 349: Django 6.1 and a DSF Executive Director
News
Call for applicants for a Django Executive Director
The DSF is hiring its first Executive Director to run fundraising, operations, staff, and legal/compliance for the Foundation. The role is US-based (no visa sponsorship). Applications (resume, optional cover letter, and a vision statement) are due September 14, 2026.
Django 6.1 released
Django 6.1 introduces model field fetch modes, database-level delete options for ForeignKey.on_delete, and dictionary-based email settings. Django 6.0 is now out of mainstream support and receives security and data loss fixes only until April 2027, so plan your upgrade before then.
Thank you to release manager Jacob Walls and the entire Django team on another happy feature release.
Releases
Django security releases issued: 6.0.8 and 5.2.17
The releases address high-severity spatial lookup flaws that could write files or make network requests, plus denial-of-service risks in language and geometry handling and potential XSS from unsafe admin URLField values. Upgrade to Django 6.0.8 or 5.2.17 as soon as possible.
Python 3.15.0 candidate 1 is here!
Python 3.15.0 candidate 1 is available for testing, giving projects a release candidate against which to check compatibility and build wheels.
Python 3.14.7 and 3.13.15 are now available!
Python 3.14.7 and 3.13.15 are available as bug-fix releases, so update your installations.
Wagtail CMS News
An agent-heavy roadmap for 2026
A standards-based look at what agent readiness requires, without the usual hype.
Sponsored Link
Find and fix Python errors faster - for free - with Honeybadger
When something breaks in production, logs tell you something happened. Honeybadger tells you why.
Honeybadger filters out noise and transforms your Python logs into context-rich issues so you can stop guessing and ship the fix faster.
Django Fellow Reports
Django Fellow Report - Jacob
Highlights this week included clearing release blockers for 6.1 and making the parallel test runner more fault tolerant. That means lots of tickets triaged, reviewed, and authored!
Django Fellow Report - Natalia
This week I prioritized time-sensitive security work 🥷, including finalizing patches, preparing and validating backports, and sending pre-notifications ahead of the release. Alongside that, I focused on Tim's "Sprint quickstart" PR 🏃➡️ and attended meetings 🎧. Otherwise, I spent time preparing my DjangoCon US talk (it is coming together well, even if I am a bit wary of expectations around my htmx expertise 🎤).
Django Fellow Report - Sarah
Focus of the week was mostly around helping finalize the security release and reviewing the GSOC Selenium to Playwright migration (which is looking in good shape!).
Articles
Django Claude Skills
Mariatta built a set of Django house rules for Claude to follow in her own projects, covering formatting (black, isort, djlint, flake8), full test coverage as a merge requirement, has_perm() over group-membership checks for permissions, and a single Markdown email template that renders both text and HTML. She's explicit that these are personal conventions, not Django community consensus, and that a project's own style wins when contributing elsewhere. She published it as an Astro static site rather than plain Markdown, since she'd rather read the rules in a browser than as agent-only files.
What I love about Django
The best parts of Django are the ones you stop noticing - a tour of the abstractions that have given Buttondown the most leverage over the years.
Django Doesn't Have to Feel Old: Modernize Your Frontend with Vite
A walkthrough of wiring django-vite into a Django project: hot module replacement so CSS edits show up without a full page reload, explicit imports instead of global script-tag collisions, and a vite_asset template tag that resolves to the dev server or hashed production files depending on DEBUG.
Django 6 isn't a revolution. And that's exactly why I like it.
An experienced developer's take on years of building applications with Django and why the latest update continues a philosophy that many modern frameworks seem to have forgotten.
Python: how time-machine is O(1) where freezegun is O(n)
The comparison explains why time-machine avoids freezegun's O(n) slowdown when mocking dates and times, building on benchmarks that found it 100 to 200 times faster across two project sizes.
Core Dispatch #9
Python 3.15.0 release candidate 1 is out, followed by maintenance releases Python 3.14.7 and 3.13.15. The latest Core Dispatch also tracks two new PEPs entering the queue.
Devtools must be open source
Agents can now rebase your local tweaks against upstream automatically, so personalizing a tool costs a prompt instead of an ongoing maintenance burden. That's the case for why closed-source tools like Claude Code can't be personalized the way open alternatives like Codex or Pi can.
DjangoCon US
Save 10% on DjangoCon US 2026 registration
DjangoCon US 2026 runs August 24 to 28 in Chicago, now under three weeks away. Register through our link to take 10% off. Time is running out to get your ticket. Get yours before they are gone!
Events
Chicago Like a Local: Things to Do During DjangoCon US 2026 (Part 1)
Conference chair Keanya Phelps rounds up Italian beef at Mr. Beef and Al's, ramen and vinyl records at Wax in West Town, shuffleboard at Electric Shuffle, and rooftop lake views at Offshore on Navy Pier. She also flags the free Chicago House Music Festival in Millennium Park, August 27 to 30, which overlaps the last days of the conference.
Django Job Board
A few openings this week, including Django and Python Software Foundation roles.
Executive Director at Django Software Foundation 🆕
Security Developer at Python Software Foundation
Senior Full Stack Engineer at Hive Collective
Senior Backend Engineer at MyOme
Python + TypeScript Engineers at Fusionbox
Videos
PyCon US 2026
PyCon US 2026 videos are up.
Projects
wemake-services/django-modern-rest
Modern REST framework for Django with types and async support!
wsvincent/django-skills
Unofficial Django skills based on Django docs and community best-practices.
07 Aug 2026 3:00pm GMT
06 Aug 2026
Planet Twisted
Hynek Schlawack: Production-ready Python Docker Containers with uv
Starting with 0.3.0, Astral's uv brought many great features, including support for cross-platform lock files uv.lock. Together with subsequent fixes, it has become Python's finest workflow tool for my (non-scientific) use cases. Here's how I build production-ready containers, as fast as possible.
06 Aug 2026 12:00am GMT
23 Jun 2026
Planet Twisted
Glyph Lefkowitz: Adversarial Communication
As I have discussed in previous posts, "AIs" can make mistakes. In fact, they do make mistakes, and their mistake-making patterns are such that where and how they will make mistakes is both uncertain and constantly changing.
Thus, in any scenario where you want to attempt to make "productive" use of "AI", you must have a system in place for checking every result. Not checking some results; checking every result. If each result might have a consequence for you (and if it didn't have a consequence, why bother automating it?) and you cannot predict in advance which kinds of results will need verification, then verification is always required.
The verification often ends up being just as expensive as doing the work in the first place, which means that if you want your usage of "AI" to be personally profitable, you have to find someone else to externalize the cost of verification onto. This person becomes your adversary, and, if you are successful, your "AI's" victim.
The Ladder-Climber And Their Reverse-Centaur Rungs
One way that this constellation of facts can straightforwardly assemble themselves into a dystopian nightmare is the phenomenon, described by Cory Doctorow, of the reverse centaur. This is when your employer non-consensually turns you into the verification system. The "AI" does the fun part of initially performing the work, and then you do the boring part where you check if the robot is right and clean up its messes, even if everyone already knows that it would, in aggregate, be cheaper for you to do the work in the first place.
Reverse centaurs can be made from any automation, not only "AI" automation. I think that there is a reason that this term happens to have emerged in the "age of AI", though, and not with earlier automation technologies (even those which were considerably more viscerally horrific). That reason is: the wrongness of "AI" output is not merely a technical feature that must be compensated for, it is a generalized externality.
As I mentioned above, if you are responsible for the entirety of the work, both extruding the "AI" output and checking it, it's usually cheaper to have humans do the entirety of the work to begin with. When humans do the writing directly, we can check as we go, and thus verification doesn't need to be as comprehensive.
When "AI" coding advocates say "code review is the bottleneck", what they are observing is that the LLM is still rolling the dice for each PR, and a human is still necessary to verify that each of those rolls is a winner. But calling this process "code review" is a bit of a misnomer; it's not really "code review" in the traditional sense, it's human understanding.
Before the advent of "AI", the human understanding was implicit in the process of writing the code in the first place1, and the code review was a way of diffusing and extending that understanding. Now that the code can be authored with no initial understanding taking place, that cost has not gone away, it has moved.
Human understanding was always the bottleneck.
However, this is taking a collaborative view of a software project, where satisfying the needs and solving the problems of your customers are the goals. We can see that "AI" is a bad tool to satisfy those goals, because all it's doing is converting the first half of the work, that of understanding the code as you write it, to understanding the agent's output as you read it.
What if, instead, we were to take the view that every software company is a Hobbesian nightmare, red in tooth and claw? In this view, the only goal of a software project is for the individual developers to make their promo cycles and get their bonuses. Given that there is only a certain amount of money to go around, this is a zero-sum game where each programmer wants to look more productive than their colleagues.
Pretty much every organization finds it easy to reward "productivity" as expressed by lines of code emitted, but the benefits of doing thorough and thoughtful design, analysis, and code review very difficult to reward. In this world, an LLM is an invaluable tool for the sociopathic ladder-climber, particularly if your legacy organization is still structuring their workflows as if the person prompting the bot is "writing" the code, and then they get to foist off the act of "reviewing" the code onto someone else.
Here, the prompter effectively externalizes the cost of the LLM's failures but internalizes any benefits. The prompter will vibe-code a big feature, so large that the assigned reviewer can't possibly comprehend it all effectively. When this happens, the reviewer will, eventually, be pressured to approve it, even if they can try to spot a few problems along the way. The reviewer has their own work to get back to, after all, the obligation to review the prompter's (read: the bot's) code is a drain on their time that they are not going to get rewarded for.
If this feature is a big success, the prompter gets a promotion. If it causes a big issue, well, the reviewer must not have been careful enough.
This is why LLMs are "good for coding", and also why their biggest promoters keep having outages.
The Generative Gish Galloper
Coding is the biggest "success story" of this type of adversarial communication, but it is by far not the only instance of such a thing. LLMs create a new form of leverage that can turn Brandolini's law from a linear advantage into an exponential one. If you are engaged in a political debate where you want to overwhelm the other side in nonsense, an LLM can generate bullshit faster than it is physically possible for a human being to type, let alone respond thoughtfully. There is an asymmetry to the utility of this weapon as well: only one side of the political spectrum wants to flood the zone and destroy trust in institutions and the concept of truth. There's a good reason that the fascists love it.
Straightforward Spam and Fraud
This is kind of obvious, but LLMs can generate lightly-customized, plausible-looking text much more quickly than any human being. This facilitates their use in fraud, spam, and scams. In a spamming or fraudulent interaction, once again, the costs are externalized onto the victim: the recipient of a spam message has to do all the work of "checking" the LLM's output. Spammers already expect very low hit rates from boilerplate, and if the LLM can increase those percentages from 1% to 5% the technology will pay for itself; they don't need anything like reliable accuracy.
Customer "Support"
If you have any kind of commercial relationship with a company, I probably don't even need to mention this: customer "support" bots are a misery. Everybody knows it at this point. But customer support is usually conceptualized by businesses as an adversarial interaction, because it is a cost center. They maintain internal metrics on time-to-resolution and try to optimize them. Implicitly, this creates a dynamic where the goal of the customer service agent's job is not to solve your problem, but to emit noise that will cause you to think your problem is resolved, or to give up, as fast as possible. Unsurprisingly, LLMs can emit this noise faster than humans can, getting those customers off the phone. But those customers will remember those interactions, and the story outside the TTR metrics is horrible.
Similarly to the situation in software development, LLMs can look very good on paper for customer support, but mostly what they are doing is illuminating the problems with the industry's existing metrics, by turning "winning the metrics battle against the customer" into a more obvious and immediate defeat for the company's long term reputation.
"Education"
In 2026 it is sadly a fact of life that students cheat all the time using "AI", and that this cheating is very successful, in that the teachers find it very hard to detect.
LLMs are great for cheating on schoolwork because the student is externalizing the work of the checking onto the teachers, who are often starting at a disadvantage to begin with, at least in the US.
My view is that this is happening because of a divergence in the way that students vs. teachers (or, more accurately, "the broader educational system") view grading.
When a student is asked to write an essay, the teachers see the effort as both intrinsically worthwhile for the student, as well as useful as a pedagogical tool to evaluate and react to the student's progress. The student, by contrast, sees a stumbling block designed to knock them off the path to success and into a permanent underclass. It is no wonder that the student sees "AI" as useful to their own goals and has no compunction about deploying it.
There is a bitter irony that the ability to understand the inherent value of actually writing the essay on their own is the sort of thing that students can really only learn by writing a bunch of essays. There's no way that I can think of which makes the benefit legible as long as a shortcut is available.
The net effect here is a downward spiral, where the already-wobbling educational system is sustaining an attack that it doesn't have the resources to recover from. The individual students' attacks against their teachers and their schools' grading systems might appear to momentarily succeed, but they will win the battle and lose the war.
Spamming "For Good"?
Usually when we talk about someone unilaterally choosing to enter into an adversarial relationship, that's an "attack" and for good reasons we have a negative impression of the attacker. However, I would be remiss if I did not point out that there are some cases where the relationship was already adversarial; just because you're the attacker doesn't mean that you are evil.
For example we might imagine use-cases like automatically filing appeals for prior authorizations against health insurance. It's relatively well-known at this point that the main way for-profit insurers maintain their margins is by denying claims right up to the line of the policies themselves being fraud, so using a spamming tool to fight them might be entirely justifiable2 in that case.
Similarly, using an LLM could be justified in a fight against a company refusing to honor a warranty. One could imagine using an LLM to immediately generate replies and escalations.
However, even in imagined cases like these, the underlying problem is that the insurers and the vendors already have a tremendous amount of structural power, so it is more likely that they will have the advantage in deploying a communications weapon like an LLM, as well as enacting policies to simply ignore any LLM-based communication that you might submit. Worse, if these strategies were to become widespread, they might provide an excuse to reject any communications by feeding them into an unreliable "LLM detector" and issuing an automated "computer says no" even to hand-written correspondence.
It is also worth stressing that these cases are imagined, as compared to the very real coworker-abuse, spam, scam, fraud, and disinformation campaigns being waged in real life today.
Therefore, while legitimate uses might exist, it's hard to imagine that there's anywhere they would be genuinely valuable and sustainable. In the best case "AI" will provide a temporary advantage for underdogs that will provoke an arms race which the resource-advantaged adversaries will win in the long run, in the worst case the arms race itself will cement permanent structural change that will make things worse.
"Search" By Stealing
Most of the adversarial utility of "AI" is on the "write" side, since write-amplification is more obviously aggressive than reading. But the "read" side of LLMs - summarization and question-answering - can be a form of attack as well.
To begin with, the act of reading itself is currently enormously destructive, but that's arguably not a fundamental aspect of this technology. They could set reasonable rate-limits and respect things like robots.txt, as search engines have for decades now. They could also refrain from committing criminal levels of copyright infringement. But, today, using "AI" tools does suborn this sort of out-of-control crawling.
More insidiously, consider the scenario described in this YouTube video. The LTT Bros decided to try Linux again, and in the course of so doing, they had problems. When trying to solve these problems, they were faced with a choice: they could consult Reddit, or they could ask an LLM. Asking an LLM would "gaslight the heck out of" them, but they still found it preferable, because they would at least get an answer without getting yelled at.
Initially this sounds great. But it also means that you want to extract knowledge from a community, while mechanically eliding any values or norms that the community may want to impart as part of offering that knowledge. As someone who spent many years in a community tech support role, this is worrying. Many requests for support are people asking how to do things that will momentarily solve a superficial problem but create a long-term reliability problem or even an immediate security risk, that the question-asker doesn't want to hear about. Consider the question "I'm tired of entering my password so much, how do I make it so my laptop unlocks automatically". An obsequious chatbot will helpfully tell you how to do this without pushback.
But, this is also a sort of ethically murky area. The Linux community is somewhat famously, for many years now, a toxic cesspool of general hostility, misogyny, etc. It is certainly a good thing that people can get access to this knowledge without subjecting themselves to abuse. But it also means that the people with the power and the privilege to change the community for the better can just quietly withdraw, rather than fixing the problems. It also means that the positive elements of culture cannot be transmitted, and people will have no opportunity to learn about unknown unknowns.
In this case, the "adversarial" communication is with society. The thing that using an LLM for search lets you do is withdraw from society and avoid forming any personal connections. There are some personal connections which are painful and annoying, and so that can feel like a momentary balm. But the need to make connections in general is, like, the concept of society itself.
Who Am I Hurting?
LLMs are good at adversarial communication. They are so good at it, relative to their other benefits, that they will tend to make communications adversarial if you are not remaining vigilant about the possibility that it might do so. My request to you, dear reader, if you are going to use such tools, is to always ask yourself, "who might I be hurting, if I use an LLM for this?"
If you're using an "AI", who is its adversary? If you haven't given it one yet, who might the "AI" turn into an adversary? Who might you overwhelm with an asymmetric amount of output, or, if you're receiving information and not sending it, who are you taking that information from without consulting?
Figure out the answers to these questions and conduct yourself accordingly; the answer might be "yourself".
Acknowledgments
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!
-
One of the reasons that software developers tend to prefer greenfield development is that when you are given a blank page, you can project your own specific understanding onto it. You can structure the codebase in a way that works for your brain, down to the variable naming conventions and the module layouts. LLM-assisted development makes everything into instant brownfield work, which makes developers instantly miserable; even those who are excited about the technology will frequently complain about how it feels like their agency has been stolen and their joy in the work has been diminished. But I digress. ↩
-
Modulo the massive amount of other externalities involved in using LLMs, of course, but I don't have the time or energy to get into those here. ↩
23 Jun 2026 8:06pm GMT
09 Jun 2026
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

