fidzu : python

News

uv is now supported natively - Read the Docs

Read the Docs now natively supports uv, bringing faster and simpler Python dependency installs to your docs builds.

Support the Django Software Foundation by buying PyCharm at a 30% Discount

JetBrains and the Django Software Foundation team up again to offer 30% off PyCharm while matching donations to fund Django's core development and community programs.

Django Software Foundation

DSF member of the month - Rob Hudson

Rob Hudson, creator of Django Debug Toolbar, reflects on his open source journey, Django's community spirit, and bringing Content Security Policy support into Django core.

Python Software Foundation

Announcing Python Software Foundation Fellow Members for Q1 2026! 🎉

The Python Software Foundation has announced its first 2026 class of Fellows, recognizing community leaders and contributors from around the world.

Wagtail CMS News

Save the 🌎 : Delete your Stuff!

For Earth Day, Wagtail makes the case that deleting old emails, files, and forgotten drafts is a simple way to cut digital clutter and lighten your carbon footprint.

Updates to Django

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

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

A huge congratulations on the work done at DjangoCon Europe 2026's sprint, because 4 of those PRs were merged during the sprints 🏰

News in Django:

• The undocumented function django.template.library.parse_bits() no longer accepts the takes_context argument, while the InclusionAdminNode.__init__() now takes the template tag name as the first positional argument.
• Fixed a misplaced ` in thedjango/contrib/admin/templates/admin/change_list.htmltemplate added in Django 6.0 that could be problematic when overriding thepagination` block (#37029).
• The new BitAnd, BitOr, and BitXor aggregates return the bitwise AND, OR, XOR, respectively. These aggregates were previously included only in contrib.postgres.
• The File class now always evaluates to True in boolean contexts, rather than relying on the name attribute. The built-in subclasses FieldFile, UploadedFile, TemporaryUploadedFile, InMemoryUploadedFile, and SimpleUploadedFile retain the previous behavior of evaluating based on the name attribute.

Sponsored Link

You know @login_required. Now meet @app.reasoner(). AgentField turns Python functions into production AI agents, structured output, async execution, agent discovery. Every decorator becomes a REST endpoint. Open source, Apache 2.0. Python, Go & TypeScript SDKs.

Articles

DjangoCon Europe 2026 - A Brief Report

A DjangoCon Europe talk explores using transpiled Django templates in the browser to power dynamic forms without constant server requests.

How to Safely Update Your Dependencies

A practical guide to safer dependency updates, covering hashes, GitHub Action pinning, cooldown windows, and automated upgrades to reduce supply chain risk.

Django: fixing a memory "leak" from Python 3.14's incremental garbage collection

Adam Johnson explains how a Django migration memory "leak" on Python led to a clever workaround and helped expose issues with its new garbage collector.

PDM Rocks!| stuartm.nz

PDM is winning over Django developers with an easy switch from uv, smarter dependency controls, and a polished project workflow.

DjangoCon Europe 2026 Review

A first-time speaker's perspective on DjangoCon Europe 2026 in Athens, packed with standout talks, community energy, and inspiration for the year ahead.

Djangocon Europe: Django templates on the frontend? - Christophe Henry

A DjangoCon Europe talk explores using transpiled Django templates in the browser to power dynamic forms without constant server requests.

Events

Django on the Med is back!

Django on the Med returns this September with three free days of focused Django sprints in beautiful Pescara, with registration now open.

PyBeach 2026

PyBeach returns on October 24, 2026 in Santa Monica, with tickets on sale now and its call for speakers open through June 7.

Django Job Board

Django Job Board

Junior Software Developer (Apprentice) at UCS Assist 🆕

Technical Lead at UCS Assist 🆕

Web Developer at Crossway 🆕

PyPI Sustainability Engineer at Python Software Foundation 🆕

Projects

wemake-services/django-modern-rest

Modern REST framework for Django with types and async support!

24 Apr 2026 3:00pm GMT

How can learning Rust help make you a better Python Developer? How do techniques required by a compiled language translate to improving your Python code? Christopher Trudeau is back on the show this week with another batch of PyCoder's Weekly articles and projects.

[ Improve Your Python With 🐍 Python Tricks 💌 - Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

24 Apr 2026 12:00pm GMT

In this quiz, you'll test your understanding of AI Coding Agents Guide: A Map of the Four Workflow Types.

By working through this quiz, you'll revisit the four common workflow types for AI coding agents: IDE, terminal, pull request, and cloud. You'll also get a chance to review how to match the right workflow to the task in front of you.

[ Improve Your Python With 🐍 Python Tricks 💌 - Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

24 Apr 2026 12:00pm GMT

If you've been wondering where I've been, yes, it's been quieter than usual around here. No dramatic reason. Just life, work, the usual stuff.

But one thing kept catching my attention: all the noise outside. Everyone's talking about AI writing code, agents shipping products, the death of programming. And every so often, someone asks me - usually with that slightly guilty look of someone who thinks they're about to insult my livelihood - "but do you really still need to learn Python? In this age?"

So I've been thinking about it. Properly. And I wanted to share where I've landed, because I think the answer matters and it's different from what some hot takes suggest.

Do I still need to learn to code?

The way we write computer programs is changing. I don't have a crystal ball for what programming looks like in five or ten years.

But here's the thing: neither does anyone else.

Here's what I know from watching others and experimenting with AI tools in my own work: right now, the people getting the most out of AI are the ones who already know how to code.

Here's the hierarchy as I see it today:

Where we stand today:

• No coding knowledge = Little benefit from AI

• Little coding knowledge = Intermediate benefit from AI

• Intermediate coding knowledge = Great benefit from AI

• Great coding knowledge = Superpower-like benefit from AI

We're in an era where some coding knowledge takes you much further than it could have a few years ago. That's not an argument against learning to code. It's an argument for it.

"But what about those vibe coding people? They seem to be shipping things." Some are. I'll be honest about that.

The projects I've seen from pure vibe coders tend to be smaller, tend to follow well-trodden patterns, and often hit a ceiling when something goes slightly wrong or slightly off-piste. Which is fine for a side project. I just created a useful dashboard to help me organise my day the way I want to using this approach.

But it tells you something: the AI does the heavy lifting on the known stuff. The moment something needs genuine thinking, you need the human who knows what's going on beneath the surface.

AI-Assisted Human Coding and Human-Assisted AI Coding

Most serious work right now is a partnership.

Sometimes it's AI-assisted human coding. The human drives, AI assists.

Sometimes it's human-assisted AI programming. The AI writes most of the code, but the human knows what to ask for, how to steer it toward good design, how to evaluate whether the output actually makes sense.

Even when the coding looks like it's done by AI, the person prompting and reviewing it is generally an experienced programmer. They've learned enough Python to know what's reasonable, what's a red flag, and when the AI is confidently wrong.

I've been experimenting with agentic AI over the past few weeks. I've tackled side projects I'd never have had the time for before. I didn't have the time to start then, let alone finish them. Some of that output will show up in other places - stay tuned! But not here. The Python Coding Stack is the place for my writing.

The Programming Mindset When Talking to AI Agents

Here's one thing I noticed. Talking to AI agents isn't like talking to humans. But it isn't like talking to computers (a.k.a. programming) either.

You need both qualities at the same time.

You need the clarity and communication skills you'd use with a person - explaining context, setting direction, knowing what matters, using clear language.

And you need the precision you'd use when programming - no ambiguity, clear intent, structure.

A good programmer who's also a good communicator is the best human to work with AI agents.

That's not coincidental. The same thought habits that make you an effective programmer also make you an effective prompter and reviewer when AI is involved.

I'll share some of the prompts I'm using in a future post and analyse them to discuss why I wrote what I wrote. Learning to code well gives you an unfair advantage in this new world.

There's Never Been a Better Time to Learn Python

Here's what I've convinced myself of after all this. There's never been a better time to learn Python.

A few years ago, you needed to reach an intermediate-to-advanced level before you could do something genuinely useful with Python. The bar was high. Now, with AI assistance, the bar is lower. Less Python knowledge takes you further than ever.

What used to need expertise can now be explored with curiosity and a bit of intermediate-ish-level Python.

That's not replacing deeper learning. It's making the entry point more accessible. And once you're in, you can go as deep as you want.

So yes, I'll keep coding in Python. Sometimes with a bit of help from AI. Sometimes with a lot of help from AI.

And yes, I'll keep writing about Python here, as I've always done.

The Fun Factor

Here's the thing we don't talk about enough when discussing programming. It's fun. It's challenging. It's rewarding. It's fulfilling. It's stimulating. It keeps my brain active.

I code because I enjoy it. I'll keep writing about Python because I enojoy that, too,, and because I find value in sharing here - for myself and, hopefully, for you too.

Normal service resumes here. More Python posts coming. And maybe, just maybe, some of the AI things I'm learning will make their way in, too.

Psst-did you know you can become a premium member to be a part of The Club? It would mean so much to me!

Subscribe now

Quick question:

Photo by Maksim Goncharenok

Join The Club, the exclusive area for paid subscribers for more Python posts, videos, a members' forum, and more.

Subscribe now

You can also support this publication by making a one-off contribution of any amount you wish.

Support The Python Coding Stack

For more Python resources, you can also visit Real Python-you may even stumble on one of my own articles or courses there!

Also, are you interested in technical writing? You'd like to make your own writing more narrative, more engaging, more memorable? Have a look at Breaking the Rules.

And you can find out more about me at stephengruppetta.com

24 Apr 2026 8:53am GMT

This week I have just got back from my third DjangoCon Europe. This year was Athens and once again it was an amazing experience. Made slightly stressful this time by doing a last minute talk that I had proposed but got rejected, it was a last minute cancellation that meant I got the opportunity to do so! So I spent most of the conference preparing for that in terms of slides, demo and practising. I also managed to squeeze in a lightning talk on Thursday for the online community working group to advertise it and call out that we can and should do better online as a community, there's more to do and we need help!

The main talk I did was on however essentially advertising Django prodserver, the package I've created, but framing it as an API design talk, so Django lacks a deployment API story, or running and I was focusing on running Django projects. So we lack a production story and the run server argument is that it's it doesn't really communicate actually what it's the commands doing. So I think it generated a bit of interest. Some peop I think it, lots of people appreciated it, I think, or enjoyed it.

I thoroughly enjoyed the other talks as well. There were some excellent database talks from Tim Bell at Kraken, Jake Howard from Torchbox, more folks at Kraken, Charlie and Sam talking about subatomic. A really an excellent set of talks overall this year, I could go through each one, but each I attended I either learnt something new or have a new package to experiment with later this year. Finally the keynotes are worth a mention, I caught most of Daniele's on philisophy and documentation and Carlson's was excellent to kick us off on types and his new package django-mantle. I I was very sad that I missed the sprints this year but had to get back for family commitments at the weekend which made for a fun trip home!

Finally the socials were great! My slight bias for Tuesday with a pre-conference Django social, the afterparty on Thursday was smooth with a visit to Django Gelato afterwards - would 100% recommend ffor any visit to Athens. The venue was excellent and allowed for multiple opportunities for networking with lots of folks at different times. I'm excited for already excited for 2027 where I think I might volunteer and maybe propose a talk again, but that entire depends on what happens in the next 6 months! Or perhaps next year I may be giving the US conference a go. In the meantime I'm hoping to attend Django on the Med (and/or perhaps a Django off the Med!)

23 Apr 2026 5:00am GMT

Back in February, I encountered an out-of-memory error while migrating a client project to Python 3.14. The issue occurred when running Django's database migration command (migrate) on a limited-resource server, and seemed to be caused by the new incremental garbage collection algorithm in Python 3.14.

At the time, I wrote a workaround and started on this blog post, but other tasks took priority and I never got around to finishing it. But four days ago, Hugo van Kemenade, the Python 3.14 release manager, announced that the new garbage collection algorithm will be reverted in Python 3.14.5, and the next Python 3.15 alpha release, due to reports of increased memory usage.

Here's the story of my workaround, as extra evidence that reverting incremental garbage collection is a good call.

$ heroku logs --app example-python-314-wsgk3w --num 1000 | less
...
app[release.6634]: System check identified no issues (26 silenced).
app[release.6634]: Operations to perform:
app[release.6634]: Apply all migrations: admin, auth, contenttypes, ...
app[release.6634]: Running migrations:

heroku[release.6634]: Process running mem=527M(101.5%)
heroku[release.6634]: Error R14 (Memory quota exceeded)

heroku[release.9599]: Process running mem=977M(190.3%)
heroku[release.9599]: Error R14 (Memory quota exceeded)

heroku[release.9599]: Process running mem=1033M(201.7%)
heroku[release.9599]: Error R15 (Memory quota vastly exceeded)
heroku[release.9599]: Stopping process with SIGKILL

$ memray run manage.py migrate

$ heroku ps:exec -a example-python-314-rspwtc --dyno web.1 bash
Establishing credentials... done
Connecting to web.1 on ⬢ example-python-314-rspwtc...
~ $

$ memray run --live manage.py migrate

$ memray run manage.py migrate
Writing profile results into memray-manage.py.724.bin

$ trash memray-manage.py.724.bin && heroku ps:copy -a example-python-314-rspwtc --dyno web.1 memray-manage.py.724.bin

$ memray flamegraph memray-manage.py.724.bin

class ModelState:
    ...

    def render(self, apps):
        """Create a Model object from our current state into the given apps."""
        ...
        return type(self.name, bases, body)

import atexit
import gc
import tracemalloc
import weakref
from itertools import islice

from django.db.migrations.state import ModelState

tracemalloc.start(2)

orig_render = ModelState.render

rendered_classes = weakref.WeakSet()


def wrapped_render(*args, **kwargs):
    cls = orig_render(*args, **kwargs)
    rendered_classes.add(cls)
    return cls


ModelState.render = wrapped_render


@atexit.register
def show_referrers():
    print(f"🎯 {len(rendered_classes)} classes referred to.\n")

    for cls in islice(rendered_classes, 2):
        print(f"🎁🎁🎁 {cls!r} 🎁🎁🎁")
        for i, referrer in enumerate(gc.get_referrers(cls), start=1):
            print(f"🍌 Referrer #{i}: {referrer!r}")
            if tb := tracemalloc.get_object_traceback(referrer):
                print("\n".join(tb.format(most_recent_first=True)))
            print()
        print()
        print()

🎁🎁🎁 <class '__fake__.ContentType'> 🎁🎁🎁
🍌 Referrer #1: <generator object WeakSet.__iter__ at 0x1234ef300>
  File "/.../example/core/apps.py", line 45
    for cls in islice(rendered_classes, 2):

...

🍌 Referrer #11: {'name': 'model', ..., 'model': <class '__fake__.ContentType'>}
  File "/.../.venv/lib/python3.14/site-packages/django/utils/functional.py", line 47
    res = instance.__dict__[self.name] = self.func(instance)
  File "/.../.venv/lib/python3.14/site-packages/django/db/models/fields/__init__.py", line 1210
    self.validators.append(validators.MaxLengthValidator(self.max_length))

def contribute_to_class(self, cls, name, private_only=False):
    ...
    self.model = cls
    ...

import gc

from django.core.management.commands.migrate import Command as BaseCommand


class Command(BaseCommand):
    """Extended 'migrate' command."""

    def migration_progress_callback(self, action, migration=None, fake=False):
        """
        Extend Django's migration progress reporting to force garbage
        collection after each migration. This is a workaround to keep memory
        usage low, especially because we have a low limit on Heroku. It seems
        the incremental garbage collector introduced in Python 3.14 cannot
        keep up with the migration process's tendency to create many cyclical
        objects, so our best fallback is to force collection of everything
        after each migration is applied or unapplied.

        https://adamj.eu/tech/2026/04/20/django-python-3.14-incremental-gc/
        """
        super().migration_progress_callback(action, migration=migration, fake=fake)
        if action in ("apply_success", "unapply_success"):
            gc.collect()

20 Apr 2026 4:00am GMT

Here is a useful trick that is unreasonably effective for simple computer use goals using modern terminal agents. On macOS, there has been a terminal osascript command since the original release of Mac OS X. All you have to do is suggest your agent use it and it can perform any application control action available in any AppleScript dictionary for any Mac app. No MCP set up or tools required at all. Agents are much more adapt at using rod terminal commands, especially ones that haven't changed in 30 years. Having a computer control interface that hasn't changed in 30 years and has extensive examples in the Internet corpus makes modern models understand how to use these tools basically Effortlessly. macOS locks down these permissions pretty heavily nowadays though, so you will have to grant the application control permission to terminal. But once you have done that, the range of possibilities for commanding applications using natural language is quite extensive. Also, for both Safari and chrome on Mac, you are going to want to turn on JavaScript over AppleScript permission. This basically allows claude or another agent to debug your web applications live for you as you are using them.In chrome, go to the view menu, developer submenu, and choose "Allow JavaScript from Apple events". In Safari, it's under the safari menu, settings, developer, "Allow JavaScript from Apple events". Then you can do something like "Hey Claude, would you Please use osascript to navigate the front chrome tab to hacker news". Once you suggest using OSA script in a session it will figure out pretty quickly what it can do with it. Of course you can ask it to do casual things like open your mail app or whatever. Then you can figure out what other things will work like please click around my web app or check the JavaScript Console for errors. Another very important tips for using modern agents is to try to practice using speech to text. I think speaking might be something like five times faster than typing. It takes a lot of time to get used to, especially after a lifetime of programming by typing, but it's a very interesting and a different experience and once you have a lot of practice It starts to to feel effortless.

04 Apr 2026 1:31pm GMT

I have been using macOS voice control for about three years. First it was a way to reduce pain from excessive computer use. It has been a real struggle. Decades of computer use habits with typing and the mouse are hard to overcome! Text selection manipulation commands work quite well on macOS native apps like apps written in swift or safari with an accessibly tagged webpage. However, many webpages and electron apps (Visual Studio Code) have serious problems manipulating the selection, not working at all when using "select foo" where foo is a word in the text box to select, or off by one errors when manipulating the cursor position or extending the selection. I only recently expanded my repertoire with the "start drag" and "drop" commands, previously having used "Click and hold mouse", "move cursor to x", and "release mouse". Well, now I have discovered that using "start drag x" and "drop x" makes a fantastic text selection method! This is really going to improve my speed. In the long run, I believe computer voice control in general is going to end up being faster than WIMP, but for now the awkwardly rigid command phrasing and the amount of times it misses commands or misunderstands commands still really holds it back. I've been learning the macOS Voice Control specific command set for years now and I still reach for the keyboard and mouse way too often.

16 Mar 2026 11:04am GMT

Humans Are Bad At Perceiving

Humans are not particularly good at catching bugs. For one thing, we get tired easily. There is some science on this, indicating that humans can't even maintain enough concentration to review more than about 400 lines of code at a time..

We have existing terms of art, in various fields, for the ways in which the human perceptual system fails to register stimuli. Perception fails when humans are distracted, tired, overloaded, or merely improperly engaged.

Each of these has implications for the fundamental limitations of code review as an engineering practice:

• Inattentional Blindness: you won't be able to reliably find bugs that you're not looking for.

• Repetition Blindness: you won't be able to reliably find bugs that you are looking for, if they keep occurring.

• Vigilance Fatigue: you won't be able to reliably find either kind of bugs, if you have to keep being alert to the presence of bugs all the time.

• and, of course, the distinct but related Alert Fatigue: you won't even be able to reliably evaluate reports of possible bugs, if there are too many false positives.

Never Send A Human To Do A Machine's Job

When you need to catch a category of error in your code reliably, you will need a deterministic tool to evaluate - and, thanks to our old friend "alert fatigue" above - ideally, to also remedy that type of error. These tools will relieve the need for a human to make the same repetitive checks over and over. None of them are perfect, but:

• to catch logical errors, use automated tests.
• to catch formatting errors, use autoformatters.
• to catch common mistakes, use linters.
• to catch common security problems, use a security scanner.

Don't blame reviewers for missing these things.

Code review should not be how you catch bugs.

What Is Code Review For, Then?

Code review is for three things.

First, code review is for catching process failures. If a reviewer has noticed a few bugs of the same type in code review, that's a sign that that type of bug is probably getting through review more often than it's getting caught. Which means it's time to figure out a way to deploy a tool or a test into CI that will reliably prevent that class of error, without requiring reviewers to be vigilant to it any more.

Second - and this is actually its more important purpose - code review is a tool for acculturation. Even if you already have good tools, good processes, and good documentation, new members of the team won't necessarily know about those things. Code review is an opportunity for older members of the team to introduce newer ones to existing tools, patterns, or areas of responsibility. If you're building an observer pattern, you might not realize that the codebase you're working in already has an existing idiom for doing that, so you wouldn't even think to search for it, but someone else who has worked more with the code might know about it and help you avoid repetition.

You will notice that I carefully avoided saying "junior" or "senior" in that paragraph. Sometimes the newer team member is actually more senior. But also, the acculturation goes both ways. This is the third thing that code review is for: disrupting your team's culture and avoiding stagnation. If you have new talent, a fresh perspective can also be an extremely valuable tool for building a healthy culture. If you're new to a team and trying to build something with an observer pattern, and this codebase has no tools for that, but your last job did, and it used one from an open source library, that is a good thing to point out in a review as well. It's an opportunity to spot areas for improvement to culture, as much as it is to spot areas for improvement to process.

Thus, code review should be as hierarchically flat as possible. If the goal of code review were to spot bugs, it would make sense to reserve the ability to review code to only the most senior, detail-oriented, rigorous engineers in the organization. But most teams already know that that's a recipe for brittleness, stagnation and bottlenecks. Thus, even though we know that not everyone on the team will be equally good at spotting bugs, it is very common in most teams to allow anyone past some fairly low minimum seniority bar to do reviews, often as low as "everyone on the team who has finished onboarding".

Oops, Surprise, This Post Is Actually About LLMs Again

Sigh. I'm as disappointed as you are, but there are no two ways about it: LLM code generators are everywhere now, and we need to talk about how to deal with them. Thus, an important corollary of this understanding that code review is a social activity, is that LLMs are not social actors, thus you cannot rely on code review to inspect their output.

My own personal preference would be to eschew their use entirely, but in the spirit of harm reduction, if you're going to use LLMs to generate code, you need to remember the ways in which LLMs are not like human beings.

When you relate to a human colleague, you will expect that:

1. you can make decisions about what to focus on based on their level of experience and areas of expertise to know what problems to focus on; from a late-career colleague you might be looking for bad habits held over from legacy programming languages; from an earlier-career colleague you might be focused more on logical test-coverage gaps,
2. and, they will learn from repeated interactions so that you can gradually focus less on a specific type of problem once you have seen that they've learned how to address it,

With an LLM, by contrast, while errors can certainly be biased a bit by the prompt from the engineer and pre-prompts that might exist in the repository, the types of errors that the LLM will make are somewhat more uniformly distributed across the experience range.

You will still find supposedly extremely sophisticated LLMs making extremely common mistakes, specifically because they are common, and thus appear frequently in the training data.

The LLM also can't really learn. An intuitive response to this problem is to simply continue adding more and more instructions to its pre-prompt, treating that text file as its "memory", but that just doesn't work, and probably never will. The problem - "context rot" is somewhat fundamental to the nature of the technology.

Thus, code-generators must be treated more adversarially than you would a human code review partner. When you notice it making errors, you always have to add tests to a mechanical, deterministic harness that will evaluates the code, because the LLM cannot meaningfully learn from its mistakes outside a very small context window in the way that a human would, so giving it feedback is unhelpful. Asking it to just generate the code again still requires you to review it all again, and as we have previously learned, you, a human, cannot review more than 400 lines at once.

To Sum Up

Code review is a social process, and you should treat it as such. When you're reviewing code from humans, share knowledge and encouragement as much as you share bugs or unmet technical requirements.

If you must reviewing code from an LLM, strengthen your automated code-quality verification tooling and make sure that its agentic loop will fail on its own when those quality checks fail immediately next time. Do not fall into the trap of appealing to its feelings, knowledge, or experience, because it doesn't have any of those things.

But for both humans and LLMs, do not fall into the trap of thinking that your code review process is catching your bugs. That's not its job.

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!

04 Mar 2026 5:24am GMT

22 Jan 2026 9:43am GMT

22 Jan 2026 9:43am GMT

22 Jan 2026 9:43am GMT