Planet Python

EuroPython: Humans of EuroPython: Daria Linhart Grudzień

Thu, 09 Jul 2026 17:05:57 +0000

EuroPython wouldn&apost exist without the wonderful volunteers who pour countless hours into organising it. From contracting the venue to selecting and confirming talks and workshops, hundreds of hours of loving work go into making each edition the best one yet.

Join us in celebrating one of the humans behind the keyboard. Today, we&aposre delighted to share an interview with Daria Linhart Grudzień, our Communications Lead.

Thank you for being the voice of the EuroPython community, Daria!

EP: What first inspired you to volunteer for EuroPython? And which edition of the conference was it?

I got pulled into the team in 2025, tempted with a chance to work with a friend on organising an event for juniors in tech in Czechia, which became the Beginners Day Unconference. I appreciated that a major European conference offered a program for the local community.

EP: Did you make any lasting friendships or professional connections through volunteering?

Lots! The EuroPython team is full of kind and fun people who like to do interesting things in their free time. Being a member of the core organising team gave me a chance to get to know a lot of folks. For the first time I feel like I’m going to the conference to meet up with friends.

EP: What was your primary role as a volunteer, and what did a typical day of contributing look like for you?

After doing the Humans of EuroPython interviews during the winter, I got invited to lead the Communications Team for the 2026 edition. My days include a variety of tasks,which I love. From building a productive team, working on finding media partners, occasional web development, co-ordinating with other teams, building documentation for the next edition, to making sure folks in the team enjoy contributing - I do what’s needed to make sure EuroPython speaks to our community with a friendly, slightly quirky, but always inclusive voice.

EP: Was there a moment when you felt your contribution really made a difference?

There were a few. Some of the core Python developers reached out to me personally saying that the Communications Team is doing a great job. Seeing our social media posts engage and resonate with the community is another reminder that our work is making an impact.

EP: Would you volunteer again, and why?

Absolutely. Contributing to EuroPython, I feel empowered to bring ideas, experiment, and work on impactful initiatives which benefit the community. I’ve been able to take on roles and projects which allowed me to learn, get out of my comfort zone, and grow. I hope to do more of that in the future, and this is a fantastic group of people to do this with.

EP: If you could describe the volunteer experience in three words, what would they be?

Ownership. Impact. Collaboration.

EP: Did you have any unexpected or funny experiences at EuroPython?

I got invited to talk about the conference on the Real Python Podcast. This wasn’t on my bingo card for this year 🙂

Python Software Foundation: The PSF D&I Workgroup Are Starting Office Hours in July!

Thu, 09 Jul 2026 14:11:06 +0000

Starting Tuesday 28 July, 2026, the PSF Diversity & Inclusion (D&I) Workgroup is opening its virtual doors once a month on Discord. Come chat with workgroup members from all over the world!

Doing diversity and inclusion work in tech can feel isolating sometimes. You might be organizing a meetup, writing a code of conduct, trying to get funding for your community, or helping people feel welcome, often in your spare time, and wondering if anyone else is wrestling with the same things.

They are. We are! And we would love to get all of us in the same room.

This July, the PSF D&I Workgroup will be hosting monthly office hours within Discord. These will be open, text-based conversations where we encourage you to ask questions, sha
re what you are working on, and connect with other people who care about making the Python community more welcoming.

The details

The PSF D&I Office Hours will be on the last Tuesday of every month. Because our community is spread across the globe, we will alternate between two times so we can cover as many time zones as possible:

1 PM UTC / 9 AM US Eastern
9 PM UTC / 5 PM US Eastern

Our first session will be on Tuesday, 28 July 2026 at 1 PM UTC. Here is roughly what that looks like around the world:

Region	Local time on 28 July
US Pacific, Los Angeles – (UTC-7h)	6:00 AM
US Eastern, New York – (UTC-4h)	9:00 AM
Brazil, São Paulo – (UTC-3h)	10:00 AM
UTC	1:00 PM
West Africa, Lagos – (UTC+1h)	2:00 PM
Central Europe, Amsterdam / Berlin / Madrid – (UTC+2h)	3:00 PM
East Africa, Nairobi – (UTC+3h)	4:00 PM
Iran, Tehran – (UTC+3:30h)	4:30 PM
India, New Delhi – (UTC+5:30h)	6:30 PM
China, Beijing – (UTC+8h)	9:00 PM
Japan, Tokyo – (UTC+9h)	10:00 PM
Australia, Sydney – (UTC+10h)	11:00 PM

If 6 AM in Los Angeles or 11 PM in Sydney made you wince, do not worry. The August session will be at 9 PM UTC, and we will keep alternating from there.

You will find us in the #psf-diversity channel on the PSF Discord. If you’re new to Discord, check out some Discord Basics to help you get started.

What will we talk about

Honestly? Whatever is on your mind related to Python, your communities, and D&I.

Since our workgroup exists to advise the PSF on diversity and inclusion, some conversations we are especially hoping to have include:

Ideas for policies, initiatives, and grant proposals to diversify the PSF missions. Feedback from the community about these topics will help the PSF D&I Workgroup provide recommendations to the PSF Board of Directors.
Your feedback, plain and simple. We want to understand how the PSF can better serve and grow a diverse membership, and we cannot do that without hearing from the community itself.
How things are actually going. Part of our job is measuring and sharing the PSF’s progress on its diversity initiatives, and we would rather do that in conversation with you than in a report nobody reads. We also want to understand and learn about the current state of Python communities around the world.

No camera, no mic, no pressure

Office hours are text chat only.

Show up in your pajamas, join from the bus, lurk quietly for the first twenty minutes. It is all fine.

And if you cannot make it at all, the conversation stays in the channel, so you can catch up later when it suits you. If something in the chat sparks a thought you would like to share with us directly, you are always welcome to email the workgroup at diversity-inclusion-wg@python.org.

Bring your own language

Because we are the D&I Workgroup, our members come from around the world! Alongside the main conversation, we will open threads in other languages where possible. Depending on the presence of our members, we would be happy to chat in Spanish, Portuguese, Chinese, Hindi, French or even Persian! Let us know during the office hour if you have a specific language you hope to converse in, or jump in with whichever language thread feels like home.

See you on the 28th!

The first office hour session is on Tuesday, 28 July 2026 at 1 PM UTC, in #psf-diversity on Discord.

Come say hi, even if it is just to tell us what you are working on with Python. We are really looking forward to meeting you!

Django Weblog: Last Call 2026 Django Developer Survey

Wed, 08 Jul 2026 19:31:21 +0000

Time is running out. This is the last call for the 2026 Django Developers Survey, which the Django Software Foundation is running in partnership with JetBrains.

The survey closes on July 13, 2026. It is one of the best measures we have of how Django is used, and it helps guide future technical and community decisions.

So far, over 3,100 people have responded, and we would love to push that number past 4,000. Every response helps us better understand the Django community.

This year's survey was shaped by the Django Steering Council, the Django Fellows, the Django Software Foundation Board of Directors, and several community members. Your feedback helps us understand your needs, see how you use Django, and plan for future development and community needs.

How you can help

Once you’ve done the survey, take a moment to re-share on socials and with your communities. The more diverse the answers, the better the results for all of us. We appreciate everybody helping to get the word out.

Please use the following links:

For more details, read the original announcement on the Django blog.

Mike Driscoll: New Book Release: Python Typing

Wed, 08 Jul 2026 18:46:18 +0000

I am happy to announce that my latest book, Python Typing, is now available on all platforms. You can get your copy on Gumroad or Leanpub or Amazon

Python has had type hinting support since Python 3.5, over TEN years ago! However, Python’s type annotations have changed repeatedly over the years. In Python Typing: Type Checking for Python Programmers, you will learn all you need to know to add type hints to your Python applications effectively.

You will also learn how to use Python type checkers, configure them, and set them up in pre-commit or GitHub Actions. This knowledge will give you the power to check your code and your team’s code automatically before merging, hopefully catching defects before they make it into your products.

What You’ll Learn

You will learn all about Python’s support for type hinting (annotations). Specifically, you will learn about the following topics:

Variable annotations
Function annotations
Type aliases
New types
Generics
Hinting callables
Annotating TypedDict
Annotating Decorators and Generators
Using Mypy for type checking
Mypy configuration
Using ty for type checking
ty configuration
and more!

Where to Purchase

Gumroad (PDF / epub)
Leanpub (PDF / epub)
Amazon (Kindle / paperback)

The post New Book Release: Python Typing appeared first on Mouse Vs Python.

Hugo van Kemenade: Fixing the dictionary with Python 3.14

Wed, 08 Jul 2026 16:40:05 +0000

Yes, but not the dict kind of dictionary.

When working on CPython, we often find obscure bugs elsewhere, in compilers, operating systems and elsewhere:

Rust/LLVM, clang-19, clang 21 and BOLT
GCC 13, GCC 15, glibc, readline and curses
musl fma

Since Python 3.8, the release notes have a section called “And now for something completely different”. These have included Monty Python sketches, astrophysics facts and poetry.

For Python 3.14, I’m doing all things π, pie and [mag]pie (more here). As part of the research for this important task, I looked up pi in the Oxford English Dictionary.

As we all recall from the Python 3.14.0b1 release notes, William Jones was the first person to use the π symbol to denote the circle’s circumference to its diameter in his Synopsis Palmariorum Matheseos (1706):

However, the OED’s first citation had a markup bug:

I duly reported this to the OED in July 2024; and by the next time I looked it up, in June 2025, it was fixed!

Hooray!

Header photo: Part of the definition for “get” in the OED’s 1901 forerunner, A New English Dictionary on Historical Principles (CC BY-NC-SA 2.0 Hugo van Kemenade).

Marc-André Lemburg: My 25th EuroPython - in a row😊

Wed, 08 Jul 2026 15:48:56 +0000

Next weekend, I&aposll be heading to Kraków, Poland, for my 25th EuroPython conference.

It&aposs been a long ride since the first EuroPython conference in Charleroi, Belgium, but one I wouldn&apost have wanted to miss.

This year, I&aposll be giving a talk about DuckLake, an extension to DuckDB, one of the most exciting new database systems in the last few years.

Come join in.

Cheers,
Marc-André

Python GUIs: Why Widgets Appear as Separate Windows — Understanding widget parenting in Qt and how to fix widgets that float outside your main window

Wed, 08 Jul 2026 06:00:00 +0000

Sometimes when I dynamically add widgets to tabs in my PyQt6 application, they pop out as windows instead. What's going on?

If you're dynamically adding widgets to your PyQt6 application and finding that they pop out as separate floating windows instead of appearing neatly inside your application, you're running into one of Qt's gotchas: widget parenting.

This problem usually shows up when widgets are added from a callback, event listener or signal handler. But there are a million different ways to screw this up. Let's look at why this happens and how to fix it.

How Qt decides what's a window

In Qt, every widget can optionally have a parent widget. The parent determines where a widget lives visually — a widget with a parent is drawn inside that parent. A widget without a parent becomes a top-level window, floating independently on your desktop.

This is the root cause of widgets appearing outside your main window. When you create a widget and it doesn't have a parent — either because you didn't set one, or because the parent was lost somehow — Qt treats it as a standalone window.

Here are the most common reasons widgets end up floating:

Creating widgets without a parent

python

# This widget has no parent — it will be a floating window
tabs = QTabWidget()

# This widget has a parent — it will appear inside parent_widget
tabs = QTabWidget(parent_widget)

When you add a widget to a layout, the layout assigns the parent automatically. But if something goes wrong between creation and layout insertion (like an exception, or the widget being shown prematurely), the widget stays parentless.

The safest approach is to pass a parent when creating widgets:

python

def create_new_tab(self):
    wdg = QWidget()
    layout = QGridLayout(wdg)

    tabs = QTabWidget(wdg)  # Explicitly set parent
    tab1 = QWidget(tabs)     # Explicitly set parent
    tab2 = QWidget(tabs)     # Explicitly set parent
    tabs.addTab(tab1, "Start")
    tabs.addTab(tab2, "Profile")
    layout.addWidget(tabs)

    return wdg

...although, honestly, I don't usually bother. If I know I'll be adding a widget to a layout immediately, I'll omit the parent assignment.

In an window __init__ the safety question is less relevant because, if there is an unhandled exception that blocks the adding your sub-widget to a layout, it will also block the creation of the parent window.

Accidentally recreating a widget

If you have a tab widget stored as self.w and somewhere in your code you do:

python

self.w = QTabWidget()

...the original tab widget is replaced. If the old widget gets garbage collected, all the tabs that had it as their parent suddenly become orphans — parentless widgets that float as independent windows.

Be careful not to reassign widget attributes unintentionally, especially in callbacks that might run multiple times.

Losing the parent reference

If you explicitly set a widget's parent to None, it becomes a top-level window:

python

widget.setParent(None)  # This widget is now a floating window

This sometimes happens indirectly. For example, removing a widget from a layout in certain ways can clear its parent.

A clean approach to dynamic tabs

Here's a complete, working example that dynamically adds tabs without any floating-window issues. It demonstrates the correct way to set up a QTabWidget with a "+" button that adds new tabs:

python

import sys
from PyQt6.QtWidgets import (
    QApplication, QMainWindow, QTabWidget,
    QWidget, QVBoxLayout, QLabel
)


class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.setWindowTitle("Dynamic Tabs")
        self.setFixedSize(600, 400)

        self.tabs = QTabWidget(self)
        self.tabs.currentChanged.connect(self.on_tab_changed)

        # Add an initial tab
        self.add_content_tab("Tab 1")

        # Add the "+" tab for creating new tabs
        self.tabs.addTab(QWidget(self.tabs), "+")

        self.setCentralWidget(self.tabs)

    def on_tab_changed(self, index):
        # Check if the "+" tab was clicked
        if self.tabs.tabText(index) == "+":
            self.add_new_tab()

    def add_new_tab(self):
        # Count existing content tabs (exclude the "+" tab)
        tab_count = self.tabs.count()  # includes "+"
        new_title = f"Tab {tab_count}"

        # Insert the new tab before the "+" tab
        new_tab = self.create_tab_content(new_title)
        insert_index = self.tabs.count() - 1
        self.tabs.insertTab(insert_index, new_tab, new_title)

        # Switch to the newly created tab (avoid retriggering)
        self.tabs.blockSignals(True)
        self.tabs.setCurrentIndex(insert_index)
        self.tabs.blockSignals(False)

    def add_content_tab(self, title):
        """Add a content tab before the + tab."""
        tab = self.create_tab_content(title)
        # Insert before the last tab if "+" exists, otherwise just add
        plus_index = None
        for i in range(self.tabs.count()):
            if self.tabs.tabText(i) == "+":
                plus_index = i
                break

        if plus_index is not None:
            self.tabs.insertTab(plus_index, tab, title)
        else:
            self.tabs.addTab(tab, title)

    def create_tab_content(self, title):
        """Create the widget content for a tab."""
        widget = QWidget(self.tabs)  # Parent is the tab widget
        layout = QVBoxLayout(widget)
        label = QLabel(f"Content for {title}", widget)
        layout.addWidget(label)
        return widget


app = QApplication(sys.argv)
window = MainWindow()
window.show()
sys.exit(app.exec())

A few things to notice in this example:

The main window inherits from QMainWindow, and QApplication is created separately.
Every widget is created with an explicit parent: QWidget(self.tabs), QLabel(text, widget), etc.
blockSignals(True) is used when programmatically changing the current tab to prevent the currentChanged signal from firing recursively.
New tabs are inserted before the "+" tab using insertTab, so the "+" always stays at the end.

Summary

Widget parenting is one of those things in Qt that works invisibly when everything is correct — and causes confusing visual glitches the moment something is slightly off. The good news is that once you understand the pattern, the fix is almost always the same: make sure every widget has a parent.

If you're new to PyQt6, our guide to creating your first window covers the basics of setting up a QMainWindow, while the widgets tutorial walks through the most common widgets and how to use them correctly.

For an in-depth guide to building Python GUIs with PyQt6 see my book, Create GUI Applications with Python & Qt6.

Brett Cannon: How to publish to PyPI using GitHub Actions securely

Tue, 07 Jul 2026 20:44:52 +0000

There have been several security incidents lately that involved compromising GitHub Actions workflows. This has led some to say "GitHub Actions is the weakest link" in publishing and to GitHub publishing a GitHub Actions security roadmap update. But saying it&aposs an issue and acknowledging the fact is one thing, but you still need to do the mitigation work today so you are not going to be the next headline. So this post is going to outline 3 things to do so you can publish to PyPI securely when using GitHub Actions.

But before I go any farther, I want to make 2 things very clear. One is this post is in no way meant to shame anyone into using GitHub Actions. For instance, I have heard people trying to shame maintainers into using GitHub Actions to use Trusted Publishing, and I think that&aposs wrong. Now, if you choose to use a platform that supports Trusted Publishing, then you should definitely use it. But Trusted Publishing is not a reason to change your publishing workflow if the one you have is already secure. In other words, use whatever works best for you to publish securely to PyPI, and if that&aposs GitHub Actions then this blog post is for you.

Two, the title of this post explicitly says "publishing" and not "building and publishing". Doing builds securely is a separate concern that I am not covering. The one piece of advice I will give, though, is one the Python security developer in residence gave me: you should have building and publishing be separate workflows.

With that out of the way, here are 3 steps to securing GitHub Actions for publishing to PyPI that should be relatively painless.

Use zizmor

The zizmor tool examines your GitHub Actions workflows to find things that at dubious when it comes to security. They pretty much all stem from GitHub Actions having insecure defaults in the name of convenience. There are 2 parts to using zizmor:

Make it happy
Set it up in CI

You can do those two things in whatever order you want but you need to do both to make sure you fix any current issues you have and prevent any new issues from slipping in. Luckily both things are easy to do.

Make zizmor happy

To run zizmor you can do uvx zizmor --quiet --fix .github/ , pipx zizmor --quiet --fix .github/ , or however you choose to run it. That will run zizmor and fix anything that it can in a clean way. Chances are, though, there will be three things to fix by hand.

No permissions by default

By default, the token GitHub Actions gives to your workflow via GITHUB_TOKEN is way too broad, so zizmor flags it. Easiest way to fix this issue is to turn off all permissions at the global level for a workflow and then turn any permissions you need on at the job level. So put the following at the global level of your workflow file (I personally put it just before jobs:):

permissions: {}

If you happen to need some specific permission, you can then specify it per-job so you scope it as tightly as possible. Or if you really need something for everything, you can still set it globally, but you at least you will be explicit about exactly what you want.

The reason you do this is you don&apost want some action to get a hold of your token that can do something as if you&aposre you and do something bad.

No persisted credentials after checkout

When you use the checkout action, GitHub Actions is running Git on your behalf, complete with credentials so the git checkout command works. The problem is those credentials persist passed the checkout action unless you specifically say to not keep them around. So add the following with: clause to your checkout action:

  with:
    persist-credentials: false

You do this so your credentials don&apost leak out to some action that will do something bad with them.

Pin your actions

When you specify an action to use in a workflow, you were probably told to use some Git tag like uses: actions/checkout@v7 which specifies using the v7 tag from the https://github.com/actions/checkout repo. The problem with that is if that action gets compromised, an attacker can just update that tag to point to malicious code and so now you&aposre compromised.

You work around this by pinning your actions to commit hashes. This might sound like a massive hassle, but there are tools that can pin all your actions for you.

gha-update
zizmor --fix --gh-token with a (permissionless) token
Pinact

Those go from simplest to fanciest, but they all get the job done. I personally use gha-update as it&aposs quick and updates my versions along the way. But if you want to keep your current versions as-is then zizmor will do it for you, but you need to give it a token to do the updates (the token is required to avoid being throttled by GitHub). The best thing to do is to use a permissionless token, but if you&aposre being lazy and trust zizmor (and any tool you might be using to run it, e.g. uvx), you can get a token from gh auth token (the following example is for the Fish shell; adjust the syntax for calling gh accordingly for your shell and how you prefer to call zizmor):

zizmor --quiet --fix --gh-token (gh auth token) .github

If you need fancier than any of that, use Pinact.

You also want to require pinning not only for your workflows but any actions that use actions themselves so you&aposre pinned top to bottom. The easiest way to make that a requirement is to run the following command:

gh api "/repos/{owner}/{repo}/actions/permissions" --method PUT --field enabled=true --field sha_pinning_required=true

There&aposs also a way to do it via the UI:

Screenshot of turning on required SHA pinning in a repo under Settings - Actions - General

Bonus: Dependabot to keep actions up-to-date

Dependabot will recognize your use of pins, so you can still use it to keep your actions up-to-date (if you so choose; it&aposs okay if you don&apost want to use Dependabot). The one thing I suggest is using a cooldown so you don&apost accidentally pick to a malicious update by adding a cooldown of a week to your dependabot.yml:

- package-ecosystem: github-actions
  directory: /
  schedule:
    interval: monthly
  cooldown:
    default-days: 7

Add zizmor to CI

Conveniently, zizmor has an action you can set up in your repo. Using it will cause any issues found to be reported as a code scanning result under the "Security and quality" tab (which can be turned off).

Screenshot showing the "Code scanning" view under the "Security and quality" tab on GitHub

This means the results are private and thus you don&apost have to worry about exposing anything publicly. You can also use the results as a TODO list if you would find that more motivating to have something to check off instead of getting everything working upfront. As well, if you want to do it gradually this will give you a checklist of things to fix.

You can also run zizmor manually if you want in CI, but I personally just use the zizmor action in a dedicated workflow since the zizmor docs provide such a workflow configuration.

Use Trusted Publishing

If you&aposre going to use GitHub Actions to publish to PyPI, I don&apost see any reason not to use Trusted Publishing. It means you don&apost have to manage any API tokens and you can get attestations. Basically it means you get to outsource your security concerns for how you communicate with PyPI for publishing to GitHub&aposs security team.

The one thing you should make sure to do when setting up Trusted Publishing is set up a GitHub environment. The Trusted Publishing docs strongly encourage it and so do I. You can even have the environment do nothing, but doing it now at least gives you an easy option to use it for something later. But I do suggest you use environments to ...

Require approval to publish

The one specific thing I suggest you do with your GitHub environment is require reviewers to run your publishing workflow. The required reviewer can be yourself! But the key point is to require someone to approve the workflow to run.

You might be wondering what&aposs the point if you trigger the release yourself? It&aposs to add a gate to protect against accidental running of your publishing workflow. The accident could be from you or it could be from a malicious actor who has managed to trigger the workflow. By requiring your approval, neither scenario can happen without you clicking that approval button while logged into your GitHub account. And that means someone would need to hack your GitHub account to work around it (and as mentioned above, that means you get to lean on the GitHub security team from preventing that from happening).

Out of everything I have listed, this is probably the most arduous as it&aposs a cost every time you want to do a release. But it&aposs one approval and you&aposre probably already going to be doing something to trigger the release, so you&aposre already online.

And that&aposs it! Those 3 steps get you a long way towards publishing securely from GitHub Actions to PyPI.

Acknowledgments

Thanks to Seth Larson for providing feedback on a draft of this post and giving advice on Mastodon when I posted about these steps. Thanks to William Woodruff for creating zizmor and also giving advice on Mastodon. And thanks to everyone who participated constructively in the discussion on Mastodon.

PyCoder’s Weekly: Issue #742: Wagtail as Admin, Random Values, Code Quality, and More (2026-07-07)

Tue, 07 Jul 2026 19:30:00 +0000

#742 – JULY 7, 2026
View in Browser »

Wagtail as Django Admin on Steroids

Wagtail can do pretty much everything the Django Admin can do, but includes a much more modern UI and more features. This article shows you how to use Wagtail as an Admin alternative.
TIM KAMANIN

Selecting Random Values in Python

Python’s random module provides utilities for generating pseudorandom numbers. For cryptographically-secure randomness, use the secrets module instead.
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

Managing and Measuring Python Code Quality

Master Python code quality tools like linters, formatters, type checkers, and profilers to measure, manage, and improve the code you write.
REAL PYTHON course

Discussions

The Path to a Supported JIT Compiler for CPython

PYTHON.ORG

Articles & Tutorials

Thinking About Running for the PSF Board? Let’s Talk!

The Python Software Foundation Board has announced two office-hour sessions dedicated to giving information on running for the PSF Board. If you’re thinking of running in the upcoming election, these sessions can help you understand the ins and outs.
PYTHON SOFTWARE FOUNDATION

Celery on AWS ECS: Complete Guide

Running Celery on AWS ECS without losing tasks and making sure that all the work is done is not as straightforward as it may seem. Learn how to configure Celery and structure your tasks for reliable processing.
JAN GIACOMELLI • Shared by Špela Giacomelli

Learn the Agentic Coding Workflow That Actually Works on Real Projects

65% of Python developers are stuck using AI for small tasks that fall apart on anything real. This 2-day live course (July 11-12 via Zoom) walks you through building a complete Python app with OpenAI’s Codex, from an empty directory to a shipped project on GitHub. See the Full Curriculum →
REAL PYTHON sponsor

Free-Threaded Python: Past, Present, and Future

This post summarizes a talk by core developer Thomas Wouters at PyCon US 2026 on Free-threaded Python: the attempt to remove the GIL. It describes why it is being done and what future work looks like.
JAKE EDGE

In Search of a New Contribution Model

This opinion piece from Carlton Gibson, a core Django contributor, talks about the state of contributions to OSS, how AI has made them more complicated, and how some key things are still broken.
CARLTON GIBSON

How to Get TIFF MetaData With Python

The Pillow image library gives you lots of tools for dealing with images. This article teaches you how to extract metadata from TIFF files in a few lines of Python.
MIKE DRISCOLL

Profile First: A 10x Faster Django Test Suite

Bob’s Django test suite took 30 seconds. cProfile showed 83% of it was one function: password hashing. Here’s how he found the bottleneck and the five-line fix.
BOB BELDERBOS

Python 3.15 Preview: Upgraded JIT Compiler

Learn how the upgraded Python 3.15 JIT compiler speeds up your code with a new tracing frontend, register allocation, and in-place numeric operations.
REAL PYTHON

Quiz: Python 3.15 Preview: Upgraded JIT Compiler

REAL PYTHON

Store Extra Data for Objects in a `WeakKeyDictionary`

In several programs Adam has wanted to solve the problem of associating extra data with an object. This article outlines his latest approach.
ADAM JOHNSON

How to Get Started With the GitHub Copilot CLI

Learn how to install, authenticate, and use the GitHub Copilot CLI to plan, write, and review Python code from your terminal with AI agents.
REAL PYTHON

Quiz: How to Get Started With the GitHub Copilot CLI

REAL PYTHON

Projects & Code

pytest-tia: Run Only the Tests Your Git Diff Actually Affects

GITHUB.COM/BREADMSA • Shared by BreadWasEaten

Sifty: OSS Windows Maintenance CLI

GITHUB.COM/VORTRIX5 • Shared by Amine Zouaoui

purejq: A Pure-Python Implementation of `jq`

GITHUB.COM/ADAM2GO • Shared by adam2go

supertree: Decision Tree Visualization

GITHUB.COM/MLJAR • Shared by Piotr Płoński

ninejs: Bringing Interactivity to Plotnine

GITHUB.COM/Y-SUNFLOWER

Events

Weekly Real Python Office Hours Q&A (Virtual)

July 8, 2026
REALPYTHON.COM

Python Atlanta

July 9 to July 10, 2026
MEETUP.COM

PyDelhi User Group Meetup

July 11, 2026
MEETUP.COM

DFW Pythoneers 2nd Saturday Teaching Meeting

July 11, 2026
MEETUP.COM

EuroPython 2026

July 13 to July 20, 2026
EUROPYTHON.EU

SciPy 2026

July 13 to July 20, 2026
SCIPY.ORG

EuroSciPy 2026

July 18 to July 24, 2026
EUROSCIPY.ORG

Happy Pythoning!
This was PyCoder’s Weekly Issue #742.
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 ]

PyCharm: Best Object Detection Models for Machine Learning in 2026

Tue, 07 Jul 2026 17:51:48 +0000

Object detection powers transformative applications, from autonomous vehicles navigating city streets and security systems identifying threats in real time to retail analytics tracking inventory and medical imaging detecting tumors. But choosing the right model for your computer vision project can be challenging, especially with dozens of architectures claiming superiority across different metrics.

In this guide, we’ll examine the top object detection models available in 2026, comparing their architectures, performance characteristics, and ideal use cases to help you determine which models are best suited to your applications.

Whether you’re building real-time video analytics, high-precision inspection systems, or resource-constrained edge applications, you’ll find clear guidance on which model best fits your requirements.

What is object detection?

Object detection aims to identify and localize multiple objects within images or video frames. Unlike image classification, which only classifies the broad identity of an image, object detection identifies the objects in an image/video frame and their exact positions within it.
In a nutshell, object detection solves two interdependent problems:

Localizing (detecting) the objects on the image, by drawing the bounding boxes for the objects on the image (it is possible that there are zero objects!). A bounding box is usually defined as a tuple (x, y, h, w), where x and y are the top-left coordinates of the bounding box rectangle, and h and w are the height and width of the bounding box, respectively.
Classifying the identities of these images (like a person, car, or dog).

This dual capability makes object detection more complex than classification alone, requiring models that can handle multiple objects of different sizes appearing anywhere in an image.

As with classification tasks, a simple accuracy metric is not sufficient to assess model performance. We need metrics of two types. Firstly, performance metrics that gauge the trade-off between incorrectly detecting objects (false positives) and not detecting objects at all in the image when they were present (false negatives). Secondly, we also need metrics to assess how long it will take our model to perform the task in question: We will call these compute efficiency metrics. Usually, the new architectures for object detection are benchmarked on the validation partition of the COCO dataset and run on T4 NVIDIA GPU hardware.

Here are the standard metrics used in the object detection community:

Basic building block of performance metric: Intersection over union (IoU) is the foundational geometric measure used to decide whether a predicted bounding box is correct. It is calculated as the area of overlap between the predicted box and the ground-truth box, divided by the area of their union – producing a score between 0 (no overlap) and 1 (perfect match). A detection is counted as a true positive only if its IoU with the nearest ground-truth box exceeds a chosen threshold (e.g. 0.5). A low IoU threshold is lenient about box placement; a high one demands tight localization.
Performance metric: Mean average precision (mAP), which evaluates detection accuracy by measuring how well predicted boxes overlap with ground truth annotations across different confidence thresholds. The most commonly cited variant, mAP@[50:95] (also written AP50:95), averages precision over IoU thresholds from 0.50 to 0.95 in steps of 0.05, which is a stringent measure that penalizes imprecise localization as much as missed detections.
- mAP50 vs. mAP50:95: mAP50 measures detection at IoU ≥ 0.5 and scores appear higher, favoring faster models. mAP50:95 averages across IoU thresholds 0.5–0.95 – the stricter, preferred metric. For precision-critical applications (robotics, medical), it is common to optimize for mAP50:95.

Compute efficiency metric: Frames per second (FPS), which measures inference speed, determining whether a model can process video in real-time. For standard videos, real-time is defined as >= 30 FPS (Google or original YOLO paper) or latency <= 33.3ms (1/FPS * 1000). Naturally, for such applications as self-driving cars or robotics, there are higher requirements on the FPS rate, going up as high as 60–100+ FPS.
Compute efficiency metric: Parameter count is a quality of the model that influences its performance. There is a trade-off between the model’s accuracy and its parameter count. That’s why models are provided in different sizes of the same architecture (S, M, L, XL, etc.) to cater to various scenarios of this trade-off. This is similar to the concept of parameter count in LLMs.

There are a few popular choices of datasets to evaluate the performance of object detection models. As mentioned above, the standard choice for benchmarking object detection is the COCO dataset, containing 80 object categories across 330,000 images. Naturally, there are a lot of other datasets, specialized for certain domains, such as self-driving cars, or certain scenarios, such as the detection of objects in cluttered environments. What is important to remember is that the values of object detection metrics, IoU, and mAP depend on the dataset they were evaluated on, so mAP@[50:95]=60.1 on the COCO dataset may not be directly transferable to your custom dataset. These metrics should always be re-evaluated on your dataset to define the baseline performance of the models on it.

Object detection algorithms and architecture families

Object detection models fall into two different processing flows and two different architectural families.

Architectures

CNN-based

Examples: Faster R-CNN, Mask R-CNN, Cascade R-CNN, YOLO

CNN-based detectors rely on convolutional layers to extract local features hierarchically across the image, traditionally using predefined anchor boxes as spatial priors for localizing objects. Spatial priors are predefined assumptions about where and what size objects are likely to appear in an image, giving the model a starting point for detection rather than searching randomly.

Transformer-based

Examples: RF-DETR, RT-DETR, D-FINE

Transformer-based detectors, inspired by advances in natural language processing, instead apply global self-attention mechanisms that allow the model to reason about relationships across the entire image simultaneously.

Specifically, transformer-based detectors use learned object queries and global self-attention, where each query is trained to correspond to at most one object, unlike CNN-based detectors, which build spatial understanding locally through convolutional layers with limited receptive fields.

However, in modern architectures, there exists a fusion of the two architectures: a CNN network can use self-attention modules in its architecture, such as YOLOv12 or YOLOv13, leading to cross-architectural designs.

Processing flows

Two-stage detectors

Examples: Faster R-CNN, Mask R-CNN, Cascade R-CNN

The network makes two sequential passes, each with a distinct job:

Stage 1: Region Proposal:
- Scans the image and proposes ~1000–2000 candidate regions (RoIs) that might contain objects.
- Doesn’t care about class yet, just the fact that “something interesting is here”.
- This is the region proposal network (RPN) in classic detectors
Stage 2: RoI classification and refinement:
- Takes only the proposed regions from Stage 1.
- Crops/pools features for each region.
- Predicts the exact class and refined box coordinates for each proposal.

Single-stage detectors

Examples: YOLO series, SSD, RetinaNet, DETR

The network directly predicts class labels and bounding boxes from feature maps. It does everything in one forward pass. Usually, the following happens:

A dense grid of anchor boxes (or points) is placed over the image.
For each anchor, the network simultaneously predicts:
- Whether there is an object there (objectness/class score).
- How the box should be adjusted (box regression offsets).
In older versions of single-stage detectors, one needed to filter overlapping bounding boxes at the end; it was done using the non-maximum suppression (NMS) algorithm. From YOLOv10 on, using NMS is a redundant step.

Furthermore, modern single-stage detectors have moved away from anchor-based designs entirely, predicting box coordinates directly from grid points and pixels, eliminating the need for dataset-specific anchor tuning altogether.

Historically, two-stage detectors offered better accuracy at the cost of speed, but modern single-stage detectors have largely closed this gap, achieving comparable or superior results while remaining significantly faster. Thus, we will focus on single-stage detectors only when evaluating the state-of-the-art models for practical applications.

Top object detection models in 2026

Two-stage pipelines (Faster R-CNN, Mask R-CNN) are no longer competitive. The current frontier is defined by single-stage NMS-free transformer architectures and models of the YOLO family. Each model below excels in a specific deployment scenario.

RF-DETR (by Roboflow) – Highest Accuracy

Real-Time Detection Transformer · ICLR 2026

Metric	Value
mAP50:95 (N)	48.4
mAP50:95 (M)	54.7
Latency (N)	2.3 ms
Latency (M)	4.4 ms
mAP50:95 (2XL)	60.1 (COCO record)
Latency (2XL)	21.8 ms

The strongest real-time model available. RF-DETR uses DINOv2 to extract deeply rich, globally-aware feature representations of the input image, then uses deformable cross-attention in the detection head to efficiently query those features and predict bounding boxes without needing anchor boxes or NMS post-processing. The result is a model that’s simultaneously more accurate on complex scenes and faster at inference than the naive combination of those components would suggest. RF-DETR is the first real-time detector to break 60 mAP on MS COCO. Designed from the ground up for fine-tuning, DINOv2 pre-training on internet-scale data gives it unmatched domain adaptability across aerial imagery, medical scans, industrial inspection, and more. It comes in four sizes: Nano, Small, Medium, Large (plus XL/2XL under a PML license).

Strengths:

Highest mAP of any real-time model.
Exceptional domain transfer (fine-tunes fast).
Best on occluded and complex scenes.
Supports detection + segmentation in a single API.
Apache 2.0, fully commercial-friendly.

Limitations:

Heavier than YOLO on edge/mobile.
XL/2XL models require a PML license.
Higher GPU memory vs. YOLO variants.

License: Apache 2.0 (N/S/M/L) · PML 1.0 (XL/2XL)

Repository: https://github.com/roboflow/rf-detr

YOLO12 (Tsinghua University) – Research / Benchmark

Attention-centric YOLO · NeurIPS 2025

Metric	Value
mAP50:95 (N)	40.4
mAP50:95 (M)	52.5
Latency (N)	1.60 ms
Latency (M)	4.27 ms
License	AGPL-3.0

YOLO12 is the first YOLO model to place attention mechanisms at the core rather than CNNs, matching CNN-based inference speeds while gaining the global context benefits of self-attention. Key innovations: Area attention (A²) divides feature maps into regions to reduce the quadratic cost of full self-attention; Residual ELAN (R-ELAN) stabilizes training of large attention blocks; FlashAttention reduces memory bottlenecks. It is deployable on NVIDIA Jetson, NVIDIA GPUs, and macOS.

A note on implementations. YOLO12 exists in two separate codebases, and the distinction matters in practice. The original authors (Tsinghua/University at Buffalo) actively maintain their own repository at sunsmarterjie/yolov12. In June 2025, they explicitly warned against using Ultralytics’ integration, stating it “is inefficient, requires more memory, and has unstable training” – issues they have fixed in their own repo. The training instability and memory criticisms often cited against YOLO12 are therefore criticisms of the Ultralytics port, not the model itself. Ultralytics’ recommendation to prefer YOLO26 over YOLO12 should be read with this context in mind: The comparison is partly against their own suboptimal implementation.

If you use YOLO12, install from the original repository rather than via pip install ultralytics.

Strengths:

Strong accuracy at the nano scale (beats YOLO11-N by 0.9% mAP).
Long-range context via attention mechanisms: It can take into account the entire image when detecting an object, rather than a local pixel neighborhood, as in pure CNN architectures.
Jetson-, Android-, and macOS-deployable.
Original repo fixes memory and training stability issues present in the Ultralytics port.
Actively maintained by original authors with ongoing updates (turbo variant, segmentation, and classification).

Limitations:

If using Ultralytics implementation:
- AGPL-3.0 commercial use requires an enterprise license.
- Training instability and high memory on large models.
If using an open-source implementation:
- AGPL-3.0 commercial use requires an enterprise license.
- Claims to have stable training and inference in comparison with Ulitralytics implementation.
- Requires installing from the original repo to avoid Ultralytics port issues, resulting in slightly more setup friction.
- Smaller ecosystem and community support than Ultralytics-native models.

License: AGPL-3.0 (open-source) · Enterprise license via Ultralytics for commercial use

Open-source repository: https://github.com/sunsmarterjie/yolov12

Ultralytics repository: https://github.com/ultralytics/ultralytics

YOLO26 (Ultralytics) – Best for edge / production

Edge-first unified YOLO · September 2025

Metric	Value
mAP50:95 range	40.9–57.5
Latency range	1.7–11.8 ms
CPU gain vs. YOLO11 (nano)	+43%
Unified tasks	5

Ultralytics’ flagship for 2025–2026. YOLO26 shifts focus from accuracy maximization toward deployment-oriented simplification: It removes NMS and distribution focal loss (DFL) for end-to-end inference, introduces the MuSGD optimizer for stable convergence, and adds progressive loss balancing (ProgLoss), which makes sure that the model doesn’t over-optimize one objective at the expense of others, and small-target-aware label assignment (STAL), which ensures extra attention to small objects. Five tasks are solved by this one YOLO26: detection, segmentation, pose estimation, oriented bounding boxes detection, and open-vocabulary detection and segmentation. It is explicitly designed for NVIDIA Jetson Orin/Xavier, Qualcomm Snapdragon AI, and ARM CPUs. Supports INT8 and FP16 quantization, plus ONNX, TensorRT, CoreML, and TFLite export.

Strengths:

Best edge and mobile performance (Jetson Orin and Snapdragon).
NMS-free leads to lower latency.
43% faster CPU inference than YOLO11(N) at comparable accuracy, ideal for devices without a GPU.
Five tasks in one architecture.
Stable INT8/FP16 quantization.

Limitations:

AGPL-3.0: commercial use requires an enterprise license.
Lower peak accuracy than RF-DETR XL.

License: AGPL-3.0 (open-source) · Enterprise license via Ultralytics for commercial/industrial use.

Repository: https://github.com/ultralytics/ultralytics

Benchmark comparison

To give a comparison between the models, here are the exact benchmark values. All scores on MS COCO val2017. Latency was measured on an NVIDIA T4 GPU.

Model	mAP50	mAP50:95	Latency	Params	Edge-ready	License
RF-DETR-N	67.6	48.4	2.3 ms	30.5 M	Server GPU	Apache 2.0
RF-DETR-M	73.6	54.7	4.4 ms	33.7 M	Server GPU	Apache 2.0
RF-DETR-2XL	78.5	60.1	17.2 ms	126.9 M	Server GPU	PML 1.0
YOLO12-N	56.7	40.4	1.6 ms	2.5 M	ARM / Mobile / Jetson	AGPL-3.0
YOLO12-L	70.7	53.8	5.83 ms	26.5 M	Jetson / TensorRT	AGPL-3.0
YOLO26-N	—	40.1	1.7 ms	2.4 M	ARM / Mobile / Jetson	AGPL-3.0
YOLO26-X	—	56.9	11.8 ms	55.7 M	Jetson / TensorRT	AGPL-3.0

Here is a visualization of the above results alongside additional modern object detection models for a more holistic comparison:

Use-case guidance

Occluded objects: RF-DETR (M/L) is the clear choice. Its DINOv2 backbone models global context across the full image, making it significantly better than CNN-based models at finding partially hidden objects.

Small objects: RF-DETR uses multi-scale feature extraction. YOLO26 also includes STAL (small-target-aware label assignment), making it competitive for small objects on edge hardware.

Edge / mobile / Jetson: YOLO26-N or YOLO12-N. YOLO26 is the Ultralytics recommendation for Jetson Orin/Xavier, Snapdragon AI, and ARM CPUs. It has 43% faster CPU inference than YOLO11n at comparable accuracy.

Custom domain / fine-tuning: RF-DETR by a significant margin. DINOv2 pre-training means it adapts to new domains (medical, aerial, and industrial) faster and with less data than any other model here.

Licensing Summary

Model	License	Commercial use
RF-DETR (base)	Apache 2.0	Free for all uses, including commercial products
RF-DETR XL/2XL	PML 1.0	Contact Roboflow for commercial licensing
YOLO12	AGPL-3.0	Free for open source / personal use; commercial applications require an Ultralytics Enterprise license
YOLO26	AGPL-3.0	Free for open source / personal use; commercial applications require an Ultralytics Enterprise license

Quick-start code

RF-DETR

# Install
pip install rfdetr

# Inference
from rfdetr import RFDETRBase
model = RFDETRBase()
detections = model.predict("image.jpg")

# Fine-tune on your dataset
model.train(dataset_dir="./my_dataset", epochs=50, batch_size=4)

YOLO26 / YOLO12 (via Ultralytics)

# Install
pip install ultralytics

# Inference — YOLO26
from ultralytics import YOLO
model = YOLO("yolo26n.pt")          # or yolo26s/m/l/x
results = model.predict("image.jpg")

# Inference — YOLO12
model = YOLO("yolo12n.pt")
results = model.predict("image.jpg")

# Export for edge (TensorRT / CoreML / ONNX)
model.export(format="engine")       # TensorRT for Jetson
model.export(format="coreml")       # Apple Silicon / iOS
model.export(format="tflite")       # Android / ARM

YOLO12 (use original open-source repo – not the Ultralytics integration)

# Install from the original authors' repo
conda create -n yolov12 python=3.11
conda activate yolov12
git clone https://github.com/sunsmarterjie/yolov12 && cd yolov12
pip install -r requirements.txt
pip install -e .

# Inference
from ultralytics import YOLO
model = YOLO("yolov12n.pt")         # or s/m/l/x
results = model("path/to/image.jpg")
results[0].show()

# Export for edge
model.export(format="engine", half=True)   # TensorRT FP16
model.export(format="onnx")                # ONNX for broad compatibility

Transfer learning and fine-tuning

RF-DETR – recommended for domain shift. Thanks to a DINOv2 backbone that is pre-trained on internet-scale data, fine-tuning requires less labeled data and converges faster. Use the rfdetr package with a COCO pre-trained checkpoint. Roboflow also offers a hosted fine-tuning UI.

YOLO26 / YOLO12 – easiest pipeline. Ultralytics’ training API is the most mature fine-tuning ecosystem. It supports YOLO-format and COCO-format datasets and has good documentation and an active community.

# Fine-tuning YOLO26 on a custom dataset (YOLO format)
from ultralytics import YOLO

model = YOLO("yolo26m.pt")          # start from pretrained weights
model.train(
    data="custom_dataset.yaml",     # path to your dataset config
    epochs=100,
    imgsz=640,
    batch=16,
    device=0,                       # GPU index; "cpu" for CPU
)
metrics = model.val()               # evaluate on validation set

Summary: Choosing the right model for your project

Selecting an object detection model requires matching your specific requirements against each model’s strengths. The decision framework below maps common scenarios to optimal model choices.

Your goal	Best choice	Runner-up
Highest accuracy, cloud deployment	RF-DETR M/XL	YOLO26-X
Edge / Jetson / mobile	YOLO26-N/S	YOLO12-N
Fine-tuning on a custom domain	RF-DETR	YOLO26
Occluded / complex scenes	RF-DETR	YOLO26
Research / benchmarking	YOLO12	RF-DETR
Apache 2.0 + commercial use	RF-DETR (base)	YOLO26
Multi-task (detect + segment + pose)	YOLO26	RF-DETR (det+seg)

Get started with PyCharm today

Selecting an object detection architecture in 2026 is a strategic decision dictated by the specific requirements of the application and the available computational budget. Whether prioritizing the record-breaking accuracy of RF-DETR for complex scenes or the unmatched efficiency of the YOLO family for edge deployment, the choice must balance mAP requirements against real-time latency constraints.

The landscape of computer vision is rapidly shifting toward zero-shot detection frameworks that recognize novel objects without task-specific supervision. As foundation models increasingly integrate sophisticated image embedders like CLIP or DINOv2 into detection pipelines, the boundaries of high-precision detection on resource-constrained hardware will continue to expand. While transformer-based architectures are developing quickly, the YOLO family’s established ecosystem ensures it remains a cornerstone for real-time production environments.

To achieve the best results for your specific use case, we encourage you to experiment with the models and code samples provided in this guide. To that end, PyCharm provides the perfect ecosystem for experimentation with various open-source models via Code -> Insert HF Model interface. If you’d like to try this yourself, PyCharm Pro comes with a 30-day trial.

For a hands-on starting point, this tutorial shows how to build a live object detection app using TensorFlow and PyCharm Jupyter notebooks, then deploy it on a robot – covering everything from single-frame inference to a live web dashboard with annotated detections. Moreover, stay tuned for the next tutorial post, where we will discuss all three object detection models in action.

Ari Lamstein: This Thursday: Building Data Apps with Streamlit and Copilot

Tue, 07 Jul 2026 16:00:39 +0000

On July 9 (9am–1pm Pacific) — this Thursday — I’ll be teaching a 4-hour live workshop for O’Reilly: Building Data Apps with Streamlit and Copilot.

This is the second time I’ve run this workshop, and I’ve made several improvements based on what I learned the first time.

If you work in Python and want to turn your analyses into interactive, shareable tools, this workshop is designed for you. We’ll start from a Jupyter notebook and build a complete Streamlit app that lets users explore a dataset through interactive controls, charts, and maps. Along the way, you’ll also learn to use Copilot as a companion while developing software — everything from learning the library faster to improving the quality of the code you write.

What we’ll cover

Structuring a Streamlit app
Working with user input (select boxes, filters, etc.)
Creating interactive graphics with Plotly
Organizing the UI with columns and tabs
Deploying your app to Streamlit Cloud

The workshop is hands-on: you’ll build the app step-by-step, and by the end you’ll have a working project you can adapt to your own data.

What You’ll Build

Here’s a screenshot from the app we’ll build together:

The app lets users choose a state and demographic statistic, explore how it changes over time, and view the data as a chart, map, or table.

And while the example uses demographic data, the skills you’ll learn — structuring an app, building interactive controls, and creating dynamic visualizations — apply to any Streamlit project you want to build.

Who is this for?

Data scientists and analysts who want to make their work more interactive
Python users who want to build dashboards without learning web development
Anyone curious about Streamlit or Copilot

How to Register

The workshop is hosted on O’Reilly, which is a membership platform. If you’re not already a member, O’Reilly offers a free 10-day trial — plenty of time to register and attend this week.

Register here

Also worth knowing: the workshop is recorded. So if July 9 doesn’t work for you, it’s still worth registering — you’ll have access to the recording.

I’d love to see you there.

Django Weblog: Django security releases issued: 6.0.7 and 5.2.16

Tue, 07 Jul 2026 14:00:00 +0000

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.7 and Django 5.2.16. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2026-48588: Potential exposure of private data via cached `Set-Cookie` response

django.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cache_page avoided caching responses that set a cookie while varying on Cookie only when the incoming request contained no cookies at all. When the request already carried an unrelated cookie (such as a language or theme preference cookie), the protection did not apply, allowing a response that sets a session or other sensitive cookie to be stored in Django's shared cache.

This issue has severity "low" according to the Django security policy.

Thanks to Chris Whyland for the report.

CVE-2026-53877: Heap buffer over-read in `GDALRaster`

When django.contrib.gis.gdal.GDALRaster was instantiated with a bytes object representing a raster file, the vsi_buffer property could over-read the allocated buffer by approximately 32 bytes. This could result in information disclosure of adjacent heap memory or, in rare cases, a segmentation fault. Only rasters stored in GDAL's virtual filesystem were affected.

This issue has severity "low" according to the Django security policy.

Thanks to Bence Nagy for the report.

CVE-2026-53878: Header injection possibility since `DomainNameValidator` accepted newlines in input

django.core.validators.DomainNameValidator accepted newlines in domain names. If such values were included in HTTP responses, header injection attacks were possible. Django itself wasn't vulnerable because HttpResponse prohibits newlines in HTTP headers.

The vulnerability only affected uses of DomainNameValidator outside Django form fields, as CharField strips newlines by default.

This issue has severity "low" according to the Django security policy.

Thanks to Bence Nagy for the report.

Affected supported versions

Django main
Django 6.1 (currently at beta status)
Django 6.0
Django 5.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.1 (currently at beta status), 6.0, and 5.2 branches. The patches may be obtained from the following changesets.

CVE-2026-48588: Potential exposure of private data via cached `Set-Cookie` response

On the main branch
On the 6.1 branch
On the 6.0 branch
On the 5.2 branch

CVE-2026-53877: Heap buffer over-read in `GDALRaster`

On the main branch
On the 6.1 branch
On the 6.0 branch
On the 5.2 branch

CVE-2026-53878: Header injection possibility since `DomainNameValidator` accepted newlines in input

On the main branch
On the 6.1 branch
On the 6.0 branch
On the 5.2 branch

The following releases have been issued

Django 6.0.7 (tarball | checksums)
Django 5.2.16 (tarball | checksums)

The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.

PyCon: Welcome, Kattni!

Tue, 07 Jul 2026 11:50:07 +0000

We are thrilled to welcome Kattni as the next Co-Chair and future Chair of PyCon US! You may already know Kattni from her work on CircuitPython and BeeWare, as a conference speaker, and as the Conference Chair of PyOhio since 2024. We are truly excited for what she will bring to PyCon US and its community over the next four years, and we can't wait to share that with you. In her own words:

Hello, all! I'm Kattni, and I've been a Python community organiser for nearly a decade. I'm grateful to have spent the last three years as the PyOhio conference chair. PyOhio 2017 was the first technical conference I attended, and to now be able to guide the community that accepted me so openly as a new programmer has been a wonderful experience. I was simultaneously welcomed into the CircuitPython community, and I was able to spend the next six years returning the favor, building that community from the ground up. In 2024, I found a welcoming, supportive home in the BeeWare community, and I have since been working to create a space where others can find the same. I am greatly looking forward to the opportunity to bring my experience and energy to PyCon US.

Everyone has different reasons for attending PyCon US; the event has a wide range of things to offer. For me, it's about the people -- seeing old friends and making new ones is by far my favorite part of the conference. I want to focus on helping the PyCon US community grow, to further cultivate the myriad perspectives, and increase the opportunities for everyone involved to have their own amazing and memorable experiences. When it comes down to it, PyCon US happens at all because of those who participate. It wouldn't exist without, at a very minimum, those who: organise it, run it, volunteer both before and during, submit to the CFP, speak, teach tutorials, present posters, sponsor, and attend.

I hope you'll join us next year in Long Beach, as I begin my journey helping make PyCon US a wonderful event. I'm incredibly excited to be working alongside Jon, and the rest of the staff, organisers, and volunteers, through the next four years. I'm looking forward to seeing everyone next year!

We'll have more news to share about PyCon US 2027 in the coming months. Stay tuned to the blog and newsletter for updates. We look forward to welcoming you back to Long Beach next May 12 - 18.

Python Bytes: #487 Minimum requirements

Tue, 07 Jul 2026 08:00:00 +0000

Topics covered in this episode: <ul> <li><a href="https://github.com/bootandy/dust?featured_on=pythonbytes">dust</a> - a better du</li> <li><a href="https://hermes-agent.org/?featured_on=pythonbytes">Hermes Agent</a>: The AI agent that grows with you</li> <li><a href="https://github.com/simonw/llm-coding-agent/releases/tag/0.1a0?featured_on=pythonbytes">llm-coding-agent 0.1a0</a></li> <li>Extras</li> <li>Joke</li> </ul><a href='https://www.youtube.com/watch?v=KubyT7Ttggg' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="487">Watch on YouTube</a> About the show Sponsored by us! Support our work through: <ul> <li>Our <a href="https://training.talkpython.fm/?featured_on=pythonbytes">courses at Talk Python</a></li> <li>Consulting from <a href="https://sixfeetup.com/?featured_on=pythonbytes">Six Feet Up</a></li> </ul> Connect with the hosts <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></li> </ul> Join us on YouTube at <a href="https://pythonbytes.fm/stream/live">pythonbytes.fm/live</a> to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted 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. Michael #1: <a href="https://github.com/bootandy/dust?featured_on=pythonbytes">dust</a> - a better du <ul> <li><code>du</code> + Rust = <code>dust</code> - a fast, visual, intuitive disk-usage CLI</li> <li>Run <code>dust</code> and immediately see the biggest directories and files without piping through <code>sort</code>, <code>head</code>, or <code>awk</code></li> <li>Smart recursive output focuses on what matters instead of dumping every folder</li> <li>Colored bars show relative size and parent/child hierarchy, making “where did the space go?” obvious</li> <li>Perfect for Python projects bloated by <code>.venv</code>, caches, Docker volumes, downloaded datasets, and local AI models</li> <li>Install via <code>brew</code>, <code>cargo install du-dust</code>, <code>conda-forge</code>, Scoop, Snap, deb-get, or GitHub releases</li> </ul> Calvin #2: <a href="https://github.com/astral-sh/war/blob/main/SPEC.md?featured_on=pythonbytes">A Way better ARchive format for Python packaging</a> <ul> <li>war - new archive format spec from Astral (same team as uv/ruff), v0.0.2, still no binary encoding defined yet</li> <li>Header-Index-Store layout: header IDs the file, index maps names to store offsets, store holds compressed data</li> <li>Index uses a finite-state transducer (FST) to dedupe common path prefixes across entry names</li> <li>Supports three entry types (file, directory, link) and three compression modes (store/DEFLATE/zstd), plus an "executable" metadata flag</li> <li>Unpacking is atomic - writes to a temp dir, then renames into place, so a failed extract never leaves a half-unpacked directory</li> <li>Strict name-segment rules (no NUL/control chars, no leading/trailing whitespace, blocks Windows-reserved names like CON/PRN) to avoid path traversal and cross-platform footguns</li> </ul> Michael #3: <a href="https://hermes-agent.org/?featured_on=pythonbytes">Hermes Agent</a>: The AI agent that grows with you <ul> <li>Hermes Agent is an open-source, Python-built AI agent framework from Nous Research - think ChatGPT-style assistant, but connected to your tools, files, shell, browser, calendar, memory, and messaging apps</li> <li>I’m using it in Discord as a long-running agent conversation, not just a one-off chatbot session</li> <li>Hermes can connect through a gateway to platforms like Discord, Telegram, Slack, WhatsApp, email, webhooks, and more - so the same assistant can follow you across surfaces</li> <li>In my setup, I can send Hermes voice/text from Discord, keep project context across turns as threads, and ask it to actually do things: read GitHub repos, run commands, edit files, schedule calendar events, generate drafts, and verify results</li> <li>A fun workflow: I can trigger one-shot actions from an Apple Watch shortcut - dictate a request, send it to Hermes, and have the agent execute it asynchronously</li> <li>Hermes has persistent memory, so it can remember durable preferences and facts - for example, how I like my research formatted</li> <li>It also has “skills,” which are reusable procedures the agent can load later, so Hermes can self-improve over time instead of rediscovering the same workflow repeatedly</li> <li>It supports scheduled jobs / cron-style automations, so it can proactively watch for releases, send summaries, run checks, or remind you about things</li> <li>It’s provider-agnostic: OpenRouter, Anthropic, Google, xAI, local models, Nous Portal, and others</li> <li>The big idea: Hermes turns an LLM from “a chat box I visit” into “an agent I can reach from anywhere that knows my workflows and can take real actions and learns over time.”</li> </ul> Calvin #4: <a href="https://github.com/simonw/llm-coding-agent/releases/tag/0.1a0?featured_on=pythonbytes">llm-coding-agent 0.1a0</a> <ul> <li>Simon Willison built a Claude/Codex-style coding agent on top of his <code>llm</code> library, using an alpha of the <code>llm</code> package plus his python-lib-template-repo</li> <li>Built almost entirely via prompted TDD - asked an agent to write a <a href="http://spec.md?featured_on=pythonbytes">spec.md</a>, then commit + implement with red/green tests, occasionally hitting a real OpenAI key to sanity-check</li> <li>Shipped to PyPI as an alpha: <code>uvx --prerelease=allow --with llm-coding-agent llm code</code></li> <li>Tool set mirrors familiar coding-agent primitives: read_file, edit_file (exact string replace + diff), write_file, list_files, search_files, execute_command</li> <li>Also exposes a Python API - <code>CodingAgent(model="gpt-5.5", root=..., approve=True).run(...)</code> - which Simon didn't ask for but got anyway</li> <li>Demo: <code>llm code --yolo</code> told GPT-5.5 to build a SwiftUI CLI clock; model correctly noted SwiftUI isn't really CLI-friendly and still produced an ASCII-art time display</li> </ul> Extras Calvin: <ul> <li>Slides, but for developers <a href="https://sli.dev/?featured_on=pythonbytes">https://sli.dev/</a></li> <li>Wanna reduce your token usage…. only issue is that its lossy <a href="https://github.com/teamchong/pxpipe?featured_on=pythonbytes">https://github.com/teamchong/pxpipe</a></li> <li>PEP 772 - Python Packaging Council inaugural election dates set, nominations open July 28, voting September 1-15</li> </ul> Michael: <ul> <li><a href="https://mkennedy.codes/posts/what-the-pls/?featured_on=pythonbytes">What the pls?</a> revisited!</li> </ul> Joke: <a href="https://x.com/AlfinCodes/status/2057443209127903456?featured_on=pythonbytes">Min requirements for Linux</a>

The No Title® Tech Blog: Optimize Images X now supports WEBP and drag and drop

Tue, 07 Jul 2026 06:50:00 +0000

Optimize Images X, the multi-platform desktop application that helps you reduce the file size of your images on macOS, Windows and Linux, has just been updated to version 2.1.0. This new version adds drag-and-drop, conversion to more output formats, including WebP and AVIF, a new image info window with a readable EXIF report, and a PyInstaller spec file for building standalone executables.

Seth Michael Larson: Playing the “Second Quest” of Legend of Zelda: Four Swords Adventures

Tue, 07 Jul 2026 00:00:00 +0000

The Legend of Zelda: Four Swords Adventures (FSA) was released for the Nintendo GameCube in 2004 in Japan and America and 2005 globally. The game is split into eight areas with three levels per area. Data miners discovered that there were 8 levels that were cut late into development of the game that were all mostly playable. These cut levels can be seen on The Cutting Room Floor.

In 2021 a game modding and localizing group named “Eternal Dream Arabization” and $$$Link created a mod for FSA which restored and made these previously unseen levels completable. The group used EFSAdvent (source code), a level editing tool for FSA, to make the levels completable by fixing issues and adding Force Gems where necessary.

The mod itself is a collection of map files to be inserted into the game ROM and Action Replay codes that overwrite the map file loaded when entering the final level in each respective area. Here is the full list of cut levels in order:

River Flow (1-3)
Rainy Forest (2-3)
Mountain Road (3-3)
Graveyard (4-3)
Four Descents into the Darkness (5-3)
Oasis (6-3)
Through the Blizzard (7-3)
Clouds Across the Wind (8-2)

This game is one of the least played titles in the Legend of Zelda series, selling fewer than 500,000 copies globally and hasn't yet been re-released on any platform. As far as I can tell from searching the web and YouTube there is no footage of these cut and restored levels being played. I plan to rectify this by playing all the levels on a modded GameCube and publishing the recordings to YouTube. Below is the first video of me playing "River Flow":

I'll publish more videos as I play the rest of the levels.

How to play

If you'd like to play these cut levels yourself below is a complete guide on how to do so using an emulator like Dolphin and on real GameCube hardware using Swiss. To start you need:

A legally obtained ROM of Legend of Zelda: Four Swords Adventures. I used FlippyDrive’s built-in Disk Backup utility to dump the ROMs from disks I own.
An install of Python and pyisotools
FSA Second Quest level files (FSA_SecondQuest.7z). I've mirrored these files on GitHub in case they are ever removed from Patreon.
An emulator like Dolphin or a modded GameCube with Swiss
If using a Japanese ROM of FSA+, the FSA+ English Translation Port must be applied in addition to Second Quest level files

Start by making a copy the ROM, as we'll be modifying the contents using pyisotools. Create a new directory with a Python virtual environment (python -m venv venv). Activate the virtual environment (source venv/bin/activate). Install pyisotools and its dependencies using pip, I used the following lock file to do so:

python -m pip install \
  altgraph==0.17.5 \
  astroid==4.0.4 \
  beautifulsoup4==4.15.0 \
  bs4==0.0.2 \
  certifi==2026.6.17 \
  cffi==2.0.0 \
  chardet==7.4.3 \
  charset-normalizer==3.4.7 \
  cryptography==49.0.0 \
  dill==0.4.1 \
  dolreader==1.1.1 \
  idna==3.18 \
  isort==8.0.1 \
  mccabe==0.7.0 \
  packaging==26.2 \
  pillow==12.3.0 \
  platformdirs==4.10.0 \
  pycparser==3.0 \
  pygithub==2.9.1 \
  pyinstaller==6.21.0 \
  pyinstaller-hooks-contrib==2026.6 \
  pyisotools==2.4.7 \
  pyjwt[crypto]==2.13.0 \
  pylint==4.0.6 \
  pynacl==1.6.2 \
  pyside6==6.11.1 \
  pyside6-addons==6.11.1 \
  pyside6-essentials==6.11.1 \
  qdarkstyle==3.2.3 \
  qtpy==2.4.3 \
  requests==2.34.2 \
  shiboken6==6.11.1 \
  sortedcontainers==2.4.0 \
  soupsieve==2.8.4 \
  tomlkit==0.15.0 \
  typing-extensions==4.16.0 \
  urllib3==2.7.0

If you're not interested in copy-and-pasting this command you can full-send install using python -m pip install pyisotools and cross your fingers.

From here we're going to add the modded map files to the ISO. Use the extract (E) command with pyisotools to extract the ISO to a directory:

python -m pyisotools './The Legend of Zelda- Four Swords FOR NINTENDO GAMECUBE (v1.00).iso' E --dest .

This will create a directory called root/ in the current directory with the extracted files. Copy the files from FSA_SecondQuest into the root/files/GC4Sword_usa/Boss directory:

cp FSA_SecondQuest/boss*.arc root/files/GC4Sword_usa/Boss

If you are using the Japanese ROM for FSA, at this point you'd also do the file replacements for the FS+_EN_Translation_Port files, too. For the English ROM this is not necessary.

Now we build (B) an ISO again using these new files. Make sure you've made a copy of your ROM before doing this to avoid needing to dump the ROM from the disk again.

python -m pyisotools root/ B --dest './The Legend of Zelda- Four Swords FOR NINTENDO GAMECUBE (v1.00).iso'

Now we have a modified ROM that is ready to be played! To load into the cut levels we'll need to use Action Replay cheat codes depending on our platform, either Dolphin or Swiss.

Action Replay codes

I've tested the Action Replay codes supplied by the project, and they didn't work as expected, so after testing I used the Action Replay codes from The Cutting Room Floor instead. I also added the Action Replay code to the US version for unlocking all areas and levels immediately so you can quickly visit each level. For the JP region I could not find an associated Action Replay code, but there are 100% completed save files available for each region. Remember for Dolphin you must explicitly "Enable Cheats" for these codes to work.

Action Replay codes (US)

All Adventure Mode Levels Unlocked (Codejunkies)

0450ECA8 FFFFFFFF
0450ED70 FFFFFFFF
0450EE38 FFFFFFFF

Replace Level 3 with Cut Sub-Stages (The Cutting Room Floor)

04466054 3031322E
04466084 3032322E
044660B4 3033322E
044660E4 3034322E
04466114 3035322E
04466144 3036322E
04466174 3037322E
044661A4 3038322E
044811EC 31322E63
0448121C 32322E63
0448124C 33322E63
0448127C 34322E63
044812AC 35322E63
044812DC 36322E63
0448130C 37322E63
0448133C 38322E63
04481524 31325F31
04481554 32325F31
04481584 33325F31
044815B4 34325F31
044815E4 35325F31
04481614 36325F31
04481644 37325F31
04481674 38325F31
04538A14 30313200
04538A24 30323200
04538A34 30333200
04538A44 30343200
04538A54 30353200
04538A64 30363200
04538A74 30373200
04538A84 30383200

Action Replay codes (JP)

Replace Level 3 with Cut Sub-Stages (The Cutting Room Floor)

04466054 3031322E
04466084 3032322E
044660B4 3033322E
044660E4 3034322E
04466114 3035322E
04466144 3036322E
04466174 3037322E
044661A4 3038322E
044811EC 31322E63
0448121C 32322E63
0448124C 33322E63
0448127C 34322E63
044812AC 35322E63
044812DC 36322E63
0448130C 37322E63
0448133C 38322E63
04481524 31325F31
04481554 32325F31
04481584 33325F31
044815B4 34325F31
044815E4 35325F31
04481614 36325F31
04481644 37325F31
04481674 38325F31
04538A14 30313200
04538A24 30323200
04538A34 30333200
04538A44 30343200
04538A54 30353200
04538A64 30363200
04538A74 30373200
04538A84 30383200

Swiss cheats config files

Swiss cheat codes need to be supplied in their own format. These are the same Action Replay codes as above, but in the Swiss cheats format. These files should be placed into the swiss/cheats folder on your microSD card (which you may need to create) and on boot, the cheats need to be enabled by pressing Y prior to launching the game through Swiss.

Swiss cheats config (US, G4SE01.txt)
0450ECA8 FFFFFFFF
0450ED70 FFFFFFFF
0450EE38 FFFFFFFF

Swiss cheats config (JP, G4SJ01.txt)
0450ECA8 FFFFFFFF
0450ED70 FFFFFFFF
0450EE38 FFFFFFFF

Thanks for reading ♥ I would love to hear your thoughts! Contact me via Mastodon, Bluesky, or email. Browse the blog archive. Check out my blogroll.

Rodrigo Girão Serrão: Write a coding agent from first principles: better tools

Mon, 06 Jul 2026 13:00:00 +0000

Improve the capabilities of your agent by providing it with better tools.

Introduction

This tutorial builds on the coding agent you implemented in the tutorial “Write a coding agent from first principles”. In this tutorial, you'll take your agent and improve its capabilities by implementing the text edit and bash command tools that Anthropic provides.

Why use Anthropic's tools?

In the previous tutorial you implemented a coding agent that has a few tools that it can use to read, write, and execute, code. The tool "bash" can be used to execute arbitrary commands and the tools "read", "write", "replace", and "insert", can be used to edit files.

As it turns out, these tools are so universally useful that Anthropic trained its models on specific schema definitions for these tools. The tools still run on the client side, so you'll still get tool use blocks in the API responses, but you don't have to define the schema for the tool. You just specify the tools by their Anthropic types and names, and the LLMs will happily request tool uses.

Anthropic trains their models on a number of useful tools but you'll focus your attention on two tools that emulate the functionality you already have:

Text editor tool: this tool replaces the four tools you defined to read, write, replace, and insert, text in text files
Bash tool: this tool provides a persistent bash session that can run bash commands

By replacing your tools with Anthropic's, the agent will be able to make better tool calls consistently, since Anthropic trains their models on their specific tool schemas.

The native text editor tool

To define support for Anthropic's text editor tool you need to add it to your list of tools. The name of the tool is "str_replace_based_edit_tool" and its type is "text_editor_20250728". (The type carries a versioning suffix that may influence the tool's behaviour, so make sure you use the right date suffix.)

Since you'll be using Anthropic's text editor tool, you can delete the functions read, write, replace, and insert, and the corresponding dictionaries that go in the list TOOLS. Instead, add the dictionary that specifies the Anthropic tool:

# ...
TOOLS = [
    {
        "type": "text_editor_20250728",
        "name": "str_replace_based_edit_tool",
    }
]

# Bash tool defined and added later.

For organisation purposes, you'll define the text editor tool and the bash tool in their own submodules, so create the folder tools and then create the file tools/str_replace_based_edit_tool.py under src/agent. In there, you'll define the code to handle the tool call.

The text editor tool is a 4-in-1 tool that allows you to view, replace, create, and insert, text. To disambiguate the action you want to do, the tool use request includes a command:

# Example tool use dictionary:
{
  "type": "tool_use",
  "id": "toolu_01A09q90qw90lq917835lq9",
  "name": "str_replace_based_edit_tool",
  "input": {
    "command": "view",  # <--
    # ...
  }
}

You'll use the key "command" from the...

Seth Michael Larson: Mario Kart World and “seamless” media

Mon, 06 Jul 2026 00:00:00 +0000

Mario Kart World for the Nintendo Switch 2 adds a new unique game mechanic for the series where courses that neighbor each other in the sprawling world map can physically and thematically morph over a short transitionary “lap”.

These course-connecting laps are commonly called Routes or “Intermission Tracks”. There are 202 routes connecting the 30 courses in Mario Kart World, some of which change depending on your direction between courses.

This new mechanic enables what I consider the highlight of the game: a new mode named “Knockout Tour” that is reminiscent of arcade racing games with time-based checkpoints.

Diagram showing which courses can transition to one another. Created by u/SnooHamsters6067

Previously in Mario Kart, beginning a new course meant selecting the course or Grand Prix by name in a menu. Lakitu would provide a sweeping camera fly-over of the course, highlighting the title and the challenges to come. The racers would be presented and a countdown from three would begin, with varying times to hold the throttle to boost off the starting line. After a winner had passed the finish line the placements would be tallied and the cycle would begin anew.

Mario Kart World has done away with all of this in Grand Prix, Knockout Tour, and other rally racing formats. There is no ceremony for each course, there is only beginning and ending play. The courses all blur together at the edges. This seamless approach reminded me of the many new forms of passive media participation including short-form infinite video streams, “Auto Play”, or algorithmically curated DJs and playlists.

The effects of this “seamlessness” are similar for Mario Kart World courses and other digital mediums. Despite playing Mario Kart World for many hours, I can't remember many courses by name (besides Rainbow Road). Compare that to previous Mario Kart titles, where the courses are iconic and much easier to recall from a single screenshot. I feel the same is true for media that is algorithmically curated for me versus media that I've actively chosen to engage with.

To be clear: the design and game mechanics of Mario Kart World are not even close to being as negative as some of the dark patterns in media platforms today. In Mario Kart World the mechanic is used to enable new types of play where in digital media removing seams is used to separate you from the artists and your peers, placing the platform as a necessary intermediary.

When you're a passive participant, there are no ceremonies. Ceremonies are reduced because ceremonies are inflection points that might disturb you just enough to question whether you're enjoying what you're experiencing.

You don't choose an artist based on the mood you're in. You don't need to curate a playlist ahead of time for a longer listening session. You don't select a video based on mutual interest with others. You won't be able to recall what media you've experienced, who the author was, or how to follow for future works. Is it possible to be a “fan” of media you're experiencing without the ceremony?

Thanks for reading ♥ I would love to hear your thoughts! Contact me via Mastodon, Bluesky, or email. Browse the blog archive. Check out my blogroll.

Christian Ledermann: Migrate From mypy To ty And pyrefly

Sun, 05 Jul 2026 16:29:47 +0000

I wanted to migrate one of my Python packages from mypy to ty and pyrefly. I handed this task over to Claude, and at the end I asked it to write out some guidance on how to perform it most efficiently. So what follows is AI-generated 'slop'.

This guide is not about using fastkml. It documents how fastkml itself was migrated from mypy to Astral's ty and Meta's pyrefly, so the same playbook can be replayed on other codebases with less trial and error. Keep it here because the next migration (human- or agent-driven) should start from findings, not from zero.

Running two checkers instead of one is deliberate, not incidental. ty and pyrefly disagree with each other and with mypy often enough that running only one gives a false sense of completeness. Budget for both, and expect them to catch different subsets of the same bugs.

TL;DR

Get a raw error-count baseline for both tools before touching any source. Categorize by error kind, not by file.
Look for one systemic root cause before fixing anything file-by-file. In most codebases with an optional C-extension backend (lxml, pydantic-core, orjson, etc.) there is a single architectural fix that collapses 60-90% of the noise.
Fix genuine bugs the tools surface (there will be some — both tools are pickier than mypy about Optional/union narrowing, positional-only stubs, and unpacking).
Bulk-suppress test-file "constructed-then-accessed-without-narrowing" noise scoped to tests/**, not case by case, and not by widening the rule to error kinds that could hide real bugs (invalid-argument-type is not unresolved-attribute).
Turn on strict presets, then promote specific rules the preset doesn't cover, and explicitly cut the ones that create disproportionate mechanical churn (ask a human before doing a 80-site @override sweep).
Verify: both tools clean, full test suite green (with and without optional runtime deps installed), linter clean, and the TOML re-parses.

Phase 0 — Inventory the mypy config honestly

Before deleting [tool.mypy], read what each flag actually bought you, because that's the strictness bar ty/pyrefly need to match or exceed:

mypy setting	Rough ty/pyrefly equivalent
`disallow_any_generics`	ty `missing-type-argument = "error"`
`warn_redundant_casts`	ty `redundant-cast`; pyrefly `redundant-cast` (both exist, check current default level)
`warn_unused_ignores`	ty `unused-ignore-comment` / `unused-type-ignore-comment`; pyrefly `unused-ignore` (on by default under `strict`)
`warn_unreachable`	pyrefly's `strict` preset covers this; ty has no exact analog — don't assume parity, spot-check
`disallow_untyped_defs`	Neither tool has a literal flag for this — `ty` infers types through unannotated bodies by default (different philosophy from mypy). Don't expect a 1:1 mapping; re-derive intent instead of hunting for the same flag name.
Per-module `disable_error_code` overrides	pyrefly `[[tool.pyrefly.sub-config]]` + `matches` glob; ty `[[tool.ty.overrides]]` + `include` glob

Also inventory stale per-module overrides — a mypy config that's been edited over years accumulates dead entries (a module path that was renamed or deleted, but the override survived). Grep for the referenced paths; don't carry dead config forward.

Phase 1 — Install both tools and get a baseline

uv pip install ty pyrefly
ty check <src> <tests>
pyrefly check <src> <tests>

Immediately categorize, don't read line by line yet:

ty check <src> <tests> 2>&1 | grep -oE '^error\[[a-zA-Z-]+\]' | sort | uniq -c | sort -rn
ty check <src> <tests> 2>&1 | grep -E '^\s+-->' | sed -E 's/^\s+--> //; s/:[0-9]+:[0-9]+$//' | sort | uniq -c | sort -rn

The second command (errors by file) usually reveals the systemic cause immediately: a handful of files concentrate a disproportionate share of the errors, and they're usually the ones touching an optional/duck-typed dependency.

If a partial migration already exists in the repo (CI switched over but pyproject.toml grew broad ignore-missing-imports = ["*"] / blanket missing-attribute = "ignore" sub-configs), treat that as a red flag, not a starting point. Broad suppressions accumulated during an in-progress migration usually mean someone hit friction and silenced it rather than fixed it. Re-run with those suppressions removed to see the real baseline before deciding what's worth keeping.

Phase 2 — Find the systemic root cause first

The highest-leverage move in this kind of migration is almost never "fix errors file by file." It's finding the one architectural mismatch that both checkers are tripping over identically across dozens of call sites.

The recurring pattern: a project supports an optional, richer backend (lxml over xml.etree.ElementTree, orjson over json, ujson, a C-accelerated regex engine, etc.) via a runtime try/except import, and defines either a Protocol or just relies on structural duck-typing to abstract over both. mypy tolerated this for years via ignore_missing_imports = true, which silently treats the untyped backend as Any everywhere. Neither ty nor pyrefly degrade that gracefully by default — they'll either partially resolve the untyped backend's real (but incomplete) info, or fall back to typing it against whichever branch of the try/except does have full stubs (usually the stdlib fallback), and then report every method/kwarg the richer backend uniquely offers as invalid.

The fix, applied at the import site (not scattered across every call site):

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    # Type-checkers see the richer backend's own stubs; the preferred
    # backend's API is treated as a superset of the fallback's.
    from lxml import etree
else:
    try:
        from lxml import etree
    except ImportError:
        import xml.etree.ElementTree as etree

If the project also defines its own Protocol to abstract over both backends (e.g. types.py: class Element(Protocol): ...), consider going one step further and making that Protocol literally alias the richer backend's real type under TYPE_CHECKING, falling back to the structural Protocol only for runtime/non-typechecking purposes:

if TYPE_CHECKING:
    from lxml.etree import _Element as Element
else:
    class Element(Protocol):
        ...  # the original structural protocol, unchanged

This one change collapsed roughly 150 of ~240 diagnostics in the fastkml migration, because it fixed both the "backend-specific kwarg doesn't exist" class of errors and the "structural Protocol isn't assignable to a concrete stdlib parameter type" class in one shot (see pitfall below).

If a stub package exists for the richer backend (lxml-stubs, types-ujson, etc.), add it to your typing dev-dependencies — but read the pitfalls section before assuming it's a strict improvement for both checkers.

Pitfalls (the part worth re-reading before your second migration)

1. `# type: ignore[code]` is not portable

Neither ty nor pyrefly parses mypy's bracketed error-code suppression the way mypy does.

ty honors a bare # type: ignore (no brackets) as a blanket suppression for that line, but a bracketed # type: ignore[some-code] is not recognized as a ty-ignore at all — it's inert noise as far as ty is concerned, and the underlying error still fires.
pyrefly does honor # type: ignore[...] by default (its --enabled-ignores defaults to type,pyrefly), so bracketed mypy comments mostly still work for pyrefly specifically.
Both tools have their own dedicated syntax: # ty: ignore[rule-name] and # pyrefly: ignore / # pyrefly: ignore[error-kind].

Verify empirically before trusting any of this — behavior can change between tool versions:

def f() -> int:
    return "y"  # type: ignore[return-value]

Run ty check and pyrefly check against a two-line repro before deciding on a suppression strategy for the whole codebase.

Practical rule that worked well: keep the original # type: ignore[code] comment (documents intent, keeps pyrefly happy) and append # ty: ignore[rule-name] on the same physical line for ty. Don't strip the mypy-era comments outright; they're free documentation of why a line is exceptional.

2. pyrefly's TOML keys are snake_case even though its CLI flags are kebab-case

This is the single most time-consuming mistake to make. pyrefly check --replace-imports-with-any 'lxml.*' works from the CLI. Writing the "obvious" TOML equivalent:

[tool.pyrefly]
replace-imports-with-any = ["lxml.*"]   # WRONG — silently different key

...does not raise an error from pyrefly check in some code paths, but it does hard-fail with pyrefly dump-config (unknown variant 'replace-imports-with-any'... Fatal configuration error), and depending on invocation order this can also break pyrefly check itself later. The correct TOML key uses underscores:

[tool.pyrefly]
replace_imports_with_any = ["lxml.*"]

Meanwhile, error-kind names (used as dict keys under [tool.pyrefly.errors] or inside a rules = {...} table) do use hyphens (missing-override-decorator, redundant-cast, etc.) — matching the CLI's --error/--ignore rule-name spelling, not the config-field spelling. There is no single consistent casing convention across the whole config surface; check pyrefly dump-config after every config change, not just pyrefly check, because check can look clean while a nearby key is silently ignored.

After any pyrefly config edit, run both pyrefly dump-config (schema/parse validation) and pyrefly check (behavioral validation) — one catches structural mistakes the other doesn't surface.

3. pyrefly's `[[tool.pyrefly.sub-config]]` array-of-tables is fragile against interleaving

Pyrefly's per-path overrides use TOML's array-of-tables syntax:

[[tool.pyrefly.sub-config]]
matches = "tests/**/*"

[tool.pyrefly.sub-config.errors]
missing-attribute = "ignore"

TOML allows other, unrelated top-level tables to appear between [[tool.pyrefly.sub-config]] and its paired [tool.pyrefly.sub-config.errors] — the nested table still binds to the most-recently-opened array element regardless of what's interleaved. That means a pyproject.toml that grew organically (auto-migration tooling appending blocks near whatever happened to be at the end of the file) can end up with three sub-config blocks scattered across 100+ lines of unrelated project/tool config, and it will still parse. It becomes a landmine the moment someone (or an agent) deletes one [[tool.pyrefly.sub-config]] header without also deleting its now-orphaned [tool.pyrefly.sub-config.errors] block — the orphaned errors table then either binds to the wrong array element or breaks parsing entirely.

Fix: keep every pyrefly (and ty) config block contiguous in one place in the file, even if that means moving it away from wherever an automated tool first inserted it. Re-parse after every edit:

python3 -c "import tomllib; tomllib.load(open('pyproject.toml','rb')); print('OK')"

4. A `Protocol` is not assignable to a concrete class parameter

If your duck-typing abstraction is a Protocol (say, types.Element) and internal code passes Element-typed values into functions that are typed against the concrete stdlib/third-party class (xml.etree.ElementTree.SubElement(parent: Element[Any], ...)), both ty and pyrefly will reject it — even though the Protocol is structurally compatible at every call site. Protocol → concrete-class assignability doesn't work the way concrete → Protocol does, and a mutable/invariant attribute (text: str on the Protocol vs. text: str | None on the real class) makes it worse.

This resolves itself for free once you apply the Phase 2 fix (alias the Protocol to the real backend's type under TYPE_CHECKING) for internal, backend-facing code. Keep the original Protocol only for the codebase's genuinely-public, backend-agnostic API surface.

5. Registry/callback-style dispatch can't be narrowed at the signature level

A common pattern: a generic dispatch table stores classes: tuple[type[object], ...] and a matching Protocol requires every registered callback to accept exactly that (necessarily wide) signature, even though any individual callback only ever receives one concrete class at runtime. You cannot narrow an individual callback's parameter type to the concrete class it actually expects (tuple[type[SpecificClass], ...]) — that breaks structural assignability against the wider Protocol the dispatcher requires (parameter types are contravariant; a callback that only accepts a narrower type can't stand in for one the dispatcher will call with the wider type).

Fix at the call site inside the function body instead of the signature: cast("tuple[type[SpecificClass], ...]", classes), or cls = cast("type[SpecificClass]", classes[0]). Keep the public signature honestly wide.

6. `**heterogeneous_dict` splats can't be validated against multi-parameter constructors

fields = {"type_": DataType.int_, "name": "Integer"}
SimpleField(**fields)

Both checkers infer fields: dict[str, DataType | str] and then check every keyword argument against that whole union, rather than against each parameter's own specific type — because plain dict[str, ...] splatting isn't a TypedDict, so there's no per-key type information available. This isn't a narrowing bug or an inherent-bad-input case; it's a structural limitation of **dict splatting itself. Either convert the dict to a TypedDict (real fix, more invasive) or accept a targeted ignore comment — don't spend time trying to "fix" it any other way.

7. Community stub packages can behave differently per checker

If you add a community-maintained stub package (lxml-stubs, etc.) rather than relying on inline py.typed types, expect it to have its own bugs, and expect those bugs to manifest differently per checker. In this migration, lxml-stubs declares several attributes using the legacy stub syntax tag = ... # type: str (pre-PEP 526). ty tolerates this by falling back to Unknown for that attribute (safe, just loses precision). pyrefly mis-parses it as the attribute's type being the literal value Ellipsis, then reports every subsequent use (.strip(), .split(), slicing) as an error on a nonexistent EllipsisType method — a wave of dozens of false positives that has nothing to do with your code.

There is no fix on your side other than working around the stub bug per-checker:

[tool.pyrefly]
# Force pyrefly to treat the whole (broken-for-pyrefly) stub package as Any,
# while `ty` still gets full value from the same installed stub package.
replace_imports_with_any = ["lxml.*"]

Don't assume "we added the stub package" is the end of the story — verify both tools independently after adding any third-party stub dependency, because "more type information" is not always strictly better across tools.

8. Fixing the root cause makes old workaround `cast()`s redundant — clean them up

Once you fix the systemic issue, re-run both tools and look specifically for redundant-cast warnings. Every cast("Element", root) that existed purely to placate mypy's ignore_missing_imports fallback becomes genuinely unnecessary once the real type flows through correctly, and leaving it in is now dead weight (and a ty/pyrefly warning) rather than a workaround. This is a good automatic signal that the root-cause fix actually landed.

9. Some "strict" rules are mechanical churn, not bug-catching — decide explicitly, don't default to on

Pyrefly's strict preset (and to a lesser extent ty's optional rules) includes checks like missing-override-decorator (PEP 698 @override), which can flag dozens to low-hundreds of ordinary __repr__/__init__/method overrides in any codebase with meaningful inheritance. This is a legitimate check with real value in large team codebases (catches silently-broken overrides after a base-class rename), but adding @override everywhere is a large, purely mechanical diff disconnected from the actual "fix type errors" task.

Don't silently turn this on or off. Surface it explicitly (to a human reviewer, or via an explicit question if you're an agent) before deciding: disable it with a documented reason, or actually do the sweep. Either is defensible; picking silently isn't.

10. Test-file "narrowing noise" is real but should not become a license to blanket-suppress everything

The overwhelming majority of test-file errors in a mature test suite will be the same shape: construct an object, then immediately access/assign a field typed X | None or A | B | None, without a narrowing assert x is not None — because the test knows the value is set (it just set it three lines up) but the checker doesn't. This is legitimately safe to bulk-suppress scoped to the test tree:

[[tool.pyrefly.sub-config]]
matches = "tests/**/*"
[tool.pyrefly.sub-config.errors]
missing-attribute = "ignore"

[[tool.ty.overrides]]
include = ["tests/**"]
rules = { unresolved-attribute = "ignore", invalid-assignment = "ignore" }

But scope the suppressed rule names narrowly (unresolved-attribute/missing-attribute/the specific invalid-assignment shape), not broad categories like invalid-argument-type/bad-argument-type — those catch genuinely wrong types passed into calls, which do happen in test code (typos, copy-paste of the wrong fixture) and are worth keeping visible. In the fastkml migration, roughly 90% of test-file errors were narrowing noise safely bulk-suppressed, and the remaining 10% surfaced one genuine test bug (a string literal assigned where an enum member was expected) plus a batch of deliberately-invalid-input tests that just needed their ignore-comment syntax migrated (see pitfall 1).

Phase 3 — Work file by file for what's left

After the systemic fix and the bulk test-suppression, what remains is usually a short, tractable list (tens, not hundreds, of diagnostics). For each:

Read the surrounding code before deciding how to fix it. The same unresolved-attribute shape can be a real narrowing gap (add assert x is not None, matching the style already used elsewhere in the file), a genuine latent bug (an off-by-one/empty-tuple case an unpacking *args call didn't guard against), or a structural dispatch limitation (pitfall 5).
Prefer a real fix over a cast or ignore wherever one exists cheaply: correcting a wrong return-type annotation (Optional[X] that never actually returns None), adding isinstance narrowing instead of a loose dict-dispatch, genericizing a find/find_all-style utility with @overload + a TypeVar instead of returning object.
Use cast() with a one-line comment explaining *why* when the limitation is structural (pitfalls 4-6), not because you're in a hurry.
Re-run the checker on just that file after each fix (ty check path/to/file.py) — faster feedback loop than re-running the whole tree, and it confirms the fix didn't introduce a new diagnostic in the same file.

Phase 4 — Tighten to "maximum quality"

Once both tools report zero errors on the fixed baseline, raise the bar deliberately rather than assuming the default preset is already strict:

[tool.pyrefly]
preset = "strict"   # not "legacy" / "default" — legacy exists specifically to ease mypy migrations, it's a floor, not a target

[tool.ty.rules]
# Promote rules ty ships at warn/ignore by default; discover the full list with `ty explain rule`.
possibly-missing-attribute = "error"
possibly-missing-import = "error"
possibly-unresolved-reference = "error"
missing-type-argument = "error"
unused-ignore-comment = "error"
unused-type-ignore-comment = "error"
redundant-cast = "error"

Discover what's available rather than guessing:

ty explain rule                 # every rule, default level, rationale, examples
pyrefly check --help            # --preset options, --error/--warn/--ignore, --replace-imports-with-any, etc.
pyrefly dump-config             # what's actually active for this project right now

Phase 5 — Verify

Don't call it done on "the type checker is quiet." Run the full loop:

ty check <src> <tests>
pyrefly check <src> <tests>
ruff check --no-fix <src> <tests>          # type-fix edits (casts, isinstance, overloads) can introduce lint issues
ruff format --check <src> <tests>
python -m pytest                            # with optional runtime deps installed
uv pip uninstall <optional-dep>             # e.g. lxml
python -m pytest -m "not <slow-marker>"     # confirm the fallback code path still works
uv pip install -e ".[typing,<optional-dep>]"
python3 -c "import tomllib; tomllib.load(open('pyproject.toml','rb'))"

The "uninstall the optional dependency and re-run tests" step matters specifically because Phase 2's fix changes how the optional backend is typed, not just how it's imported — if the runtime fallback logic was touched at all while chasing type errors, this is the step that catches a broken fallback path before it ships.

Case study numbers (fastkml)

For calibration on what "a lot of noise, mostly one root cause" looks like in practice:

Baseline: ty reported 237 diagnostics across source + tests; pyrefly reported 40 errors (with an already-too-permissive config suppressing 38 more).
One import-site fix (Phase 2, aliasing the duck-typed Element Protocol and etree module to lxml's real stubs under TYPE_CHECKING) collapsed ty's source-only count from 47 to 13 in a single step.
Total genuine bugs found and fixed in library source: 5 (a missed .getroot() call, an unguarded empty-tuple unpack in a zip_longest loop, a too-loose type[object] dispatch signature, a Self-in-a-list invariance issue, and one example script passing bytes where str was expected).
Total genuine bugs found and fixed in tests: 1 (a string literal compared against an enum field).
Final state: zero errors on ty check and pyrefly check for the CI-covered scope, with all pre-existing tests still passing, both with and without the optional lxml backend installed.

If you made it this far, you might be interested in the cost:

Total cost: $40.44
Total duration (API): 58m 29s
Total duration (wall): 1h 48m 15s
Total code changes: 635 lines added, 224 lines removed

Usage by model:

claude-haiku-4-5: 1.1k input, 39 output, 0 cache read, 0 cache write ($0.0013)
claude-sonnet-5: 23.1k input, 227.0k output, 106.7m cache read, 993.5k cache write ($40.44)

Sebastian Pölsterl: scikit-survival 0.28.0 released

Sun, 05 Jul 2026 16:22:05 +0000

I am pleased to announce the release of scikit-survival 0.28.0.

A highlight of this release is the support for Polars DataFrames alongside pandas DataFrames via the Narwhals dataframe abstraction layer. In addition, this release adds support for scikit-learn 1.9.

Support for Polars

Polars is a data frame library similar to pandas, but with its core written in Rust instead of Python, which often gives Polars an advantage in terms of performance.

All datasets shipped with scikit-survival can now be loaded as a Polars DataFrame by specifying the output_type argument.

from sksurv.datasets import load_gbsg2
# return X as a polars DataFrame
X, y = load_gbsg2(output_type="polars")
X.head()

shape: (5, 8)
┌──────┬────────┬───────┬──────────┬────────┬─────────┬────────┬───────┐
│ age ┆ estrec ┆ horTh ┆ menostat ┆ pnodes ┆ progrec ┆ tgrade ┆ tsize │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ f64 ┆ f64 ┆ enum ┆ enum ┆ f64 ┆ f64 ┆ enum ┆ f64 │
╞══════╪════════╪═══════╪══════════╪════════╪═════════╪════════╪═══════╡
│ 70.0 ┆ 66.0 ┆ no ┆ Post ┆ 3.0 ┆ 48.0 ┆ II ┆ 21.0 │
│ 56.0 ┆ 77.0 ┆ yes ┆ Post ┆ 7.0 ┆ 61.0 ┆ II ┆ 12.0 │
│ 58.0 ┆ 271.0 ┆ yes ┆ Post ┆ 9.0 ┆ 52.0 ┆ II ┆ 35.0 │
│ 59.0 ┆ 29.0 ┆ yes ┆ Post ┆ 4.0 ┆ 60.0 ┆ II ┆ 17.0 │
│ 73.0 ┆ 65.0 ┆ no ┆ Post ┆ 1.0 ┆ 26.0 ┆ II ┆ 35.0 │
└──────┴────────┴───────┴──────────┴────────┴─────────┴────────┴───────┘

Transforming DataFrames

scikit-learn enables transformers to return Polars data frames via the set_output API.

from sklearn import set_config
from sklearn.preprocessing import StandardScaler
set_config(transform_output="polars")
# standarize the columns of a polars DataFrame
X_standarized = StandardScaler().fit_transform(
X.select("age", "tsize")
)

scikit-surival has two transformers that now accept polars and pandas data frames as input: ClinicalKernelTransform, and OneHotEncoder.

ClinicalKernelTransform

ClinicalKernelTransform computes a kernel matrix, so the output will be a numpy array, as before. With scikit-survival 0.28.0, it is aware of the polars colum types String, Categorical, Enum and Object. However, polars does not have a concept similar to ordered categories in pandas: pd.Categorical([…], ordered=True).

When computing the clinical kernel for a polars data frame, you can specify the order of categories with the ordinal_categories argument, otherwise all non-numeric columns will be treated as nominal columns, where values have no specific order (e.g. the column horTh with values “yes” and “no” in the example below).

from sksurv.kernels import ClinicalKernelTransform
K = ClinicalKernelTransform(
ordinal_categories={"tgrade": ["I", "II", "III"]},
).fit_transform(
X.select("age", "horTh", "tgrade")
)

OneHotEncoder

OneHotEncoder encodes the string-type columns to numeric columns. It automatically returns a data frame of the same type as the input:

from sksurv.preprocessing import OneHotEncoder
X_onehot = OneHotEncoder().fit_transform(X.select("horTh", "tgrade"))
X_onehot.head()

shape: (5, 3)
┌───────────┬───────────┬────────────┐
│ horTh=yes ┆ tgrade=II ┆ tgrade=III │
│ --- ┆ --- ┆ --- │
│ f64 ┆ f64 ┆ f64 │
╞═══════════╪═══════════╪════════════╡
│ 0.0 ┆ 1.0 ┆ 0.0 │
│ 1.0 ┆ 1.0 ┆ 0.0 │
│ 1.0 ┆ 1.0 ┆ 0.0 │
│ 1.0 ┆ 1.0 ┆ 0.0 │
│ 0.0 ┆ 1.0 ┆ 0.0 │
└───────────┴───────────┴────────────┘

Fitting survival models

Finally, you can pass a polars data frame to the fit and predict functions of any estimator.

from sklearn.pipeline import make_pipeline
from sksurv.linear_model import CoxPHSurvivalAnalysis
pipe = make_pipeline(
OneHotEncoder(), StandardScaler(), CoxPHSurvivalAnalysis()
)
pipe.fit(X[:500], y[:500])
risk_scores = pipe.predict(X[500:])

Note that this only works for eager data frames, lazy data frames will give an error.

X_lazy = X.lazy()
pipe.fit(X_lazy[:500], y[:500])

Traceback (most recent call last):
File "example.py", line 21, in <module>
pipe.fit(X_lazy[:500], y[:500])
File "…/site-packages/sklearn/base.py", line 1403, in wrapper
return fit_method(estimator, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
…
File "…/site-packages/sksurv/_dataframe/_input.py", line 96, in ensure_eager_dataframe
_reject_polars_lazyframe(obj)
File "…/site-packages/sksurv/_dataframe/_input.py", line 84, in _reject_polars_lazyframe
raise TypeError(_LAZYFRAME_NOT_SUPPORTED_MSG)
TypeError: polars.LazyFrame is not supported; call .collect() before passing to scikit-survival.

New Contributors

A big shoutout to our two new contributors:

cakedev0 for adding support for scikit-learn 1.9
55Kamiryo for adding support for Polars data frames.

Updated Dependencies

With this release, the minimum supported version are:

Package	Minimum Version
narwhals	2.0.1
scikit-learn	1.9.0

Install

scikit-survival is available for Linux, macOS, and Windows and can be installed either

via pip:

pip install scikit-survival

or via conda

 conda install -c conda-forge scikit-survival

Core Dispatch: Core Dispatch #7

Sun, 05 Jul 2026 00:00:00 +0000

Welcome back to Core Dispatch! This edition covers June 19 through July 5, 2026. Python 3.15.0 beta 3 landed on June 23, and beta 4 is up next on July 18, with 3.13.15 and 3.14.7 following on August 4.

Last edition, we covered the Steering Council's request that the experimental JIT chart its future through a Standards Track PEP. A new PEP has now been drafted and discussion has started: PEP 836, "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython," sketches what moving the JIT from experiment to supported feature could involve, from performance expectations to interop and tooling compatibility.

PyCon US 2026 talk recordings have also started landing, and we've pulled a few from the core team into Core Team Musings below: Pablo Galindo Salgado and László Kiss Kollár on Python 3.15's new Tachyon sampling profiler, Thomas Wouters on the past, present, and future of free-threaded Python, and Emma Smith on Rust for CPython. Not everything is up yet, so expect more picks as the rest are published.

On the packaging side, the inaugural Packaging Council election dates are out. And looking ahead, EuroPython 2026 kicks off July 13, so expect a wave of talks and Language Summit coverage to pull from in a future edition.

As always, if you maintain a package or just like living on the edge, give the latest 3.15 beta a spin and file any issues you find.

Upcoming Releases

Python 3.15.0 beta 4 — Jul 18
Python 3.13.15 — Aug 04
Python 3.14.7 — Aug 04

Official News

Packaging Council Inaugural Election Dates — By Pradyun Gedam
Mitigated API authentication bypass for python.org download metadata — By Seth Larson
Python 3.15.0 beta 3 is here! — By Hugo van Kemenade
Thinking about running for the PSF Board? Let’s talk! — By Marie Nordin

PEP Updates

Merged PRs

Discussion

PEP 835: Shorthand Syntax for Annotated Type Metadata — 🔥 122 new replies · 3.1k views
PEP 832: Virtual Environment Discovery — 🔥 21 new replies · 8.3k views
PEP 836: JIT Go Brrr: The Path to a Supported JIT Compiler for CPython — 🆕 🔥 15 new replies · 975 views
PEP 822: Dedented Multiline String (d-string) — 2 new replies · 6.9k views

Core Dev Musings

Python 3.15’s Ultra-Low Overhead Interpreter Profiling Mode — By Ken Jin
PEP 814: Add frozendict built-in type — By Victor Stinner
Tachyon: Python 3.15's sampling profiler — By Pablo Galindo Salgado & László Kiss Kollár
Free-threaded Python: past, present and future — By Thomas Wouters
Rust for CPython: Making Python Safer and More Robust for Everyone — By Emma Smith

Upcoming CFPs & Conferences

EuroPython 2026 — Jul 13
SciPy 2026 — Jul 13
EuroSciPy 2026 — Jul 18
PyData PyCon Armenia 2026 — Jul 24
PyOhio 2026 — Jul 25
📋 PyCon France 2026 Deadline — Aug 01
📋 PyCon Ireland 2026 Deadline — Aug 01
📋 PyBay 2026 Deadline — Aug 01
📋 Plone Conference 2026 Deadline — Aug 01
📋 PyData Global 2026 Workshop Deadline — Aug 04

Credits

PyCon Ireland: Update on PyCon Ireland 2026: Venue Change and Extended CFP Deadline

Sat, 04 Jul 2026 00:00:00 +0000

Our booked venue, Trinity College Dublin, has informed us that it can no longer host the conference. This decision was made by the venue, and it means we can no longer confirm 17 October 2026 as our event date.

We know this is disappointing, especially for everyone who was planning to submit a talk, book travel, or simply mark the date in their calendar. We’re disappointed too, but we want to be transparent with the community as soon as we have news, rather than staying quiet while we sort things out.

What This Means Right Now

The Call for Proposals deadline has been extended to 30 August 2026. We don’t want the venue search to hold back speakers who want to share their Python knowledge, so submissions remain open, you don’t need to wait for the new venue and date to submit. Submit your proposal on our Sessionize page.
The conference date of 17 October 2026 no longer stands. We will announce a new date once we have one.
We are actively looking for a new venue in the Dublin area that can accommodate the conference. As soon as a venue and date are confirmed, we will update the website and announce it through our usual channels.
If you already submitted a talk, don’t worry, your proposal is safe. We will let speakers know the new date and venue as soon as they’re confirmed, so you can make your own arrangements in good time.

What Stays the Same

PyCon Ireland 2026 is still happening. We are treating this as a reschedule, not a cancellation.
Our commitment to the community remains unchanged, we are as enthusiastic as ever to showcase your talks, from first-time speakers to seasoned practitioners.
The team has already begun the process of securing a new venue. We will share updates as soon as there is something concrete to report.
We still welcome proposals from first-time and experienced speakers alike, across the full range of Python topics, in both full-talk (30 minutes) and lightning-talk (5 minutes) formats. See the full CFP page for submission guidelines.

How to Stay Updated

The fastest way to hear about the new venue and date is to follow us on Mastodon, X, or LinkedIn. We will also post updates here on the blog.

Thank you for your patience and continued support of Python Ireland. We look forward to sharing better news with you soon, and we can’t wait to read your proposals.

Bob Belderbos: One Core, Two Interfaces, No Rewrites

Sat, 04 Jul 2026 00:00:00 +0000

When building applications, I always build the core first, then the interfaces. It was no different with Ask the Canon: a uv run main.py ask "..." CLI for quick iteration and validation, then the web app for MVP. Search, ranking, citations, all using the same engine.

Ask the Canon's core is a handful of pure functions in one module. Both interfaces are thin wrappers. This is the second post in a series on how it's built. The first one was about the retrieval engine. This one is about the wider architecture.

Functional core, two interfaces

I just have one module with pure functions, clear contracts, and no hidden state:

def embed(texts: list[str]) -> np.ndarray: ...
def load_library(book_ids=None) -> tuple[list[Passage], np.ndarray]: ...
def search_passages(query, passages, vectors, ...) -> list[tuple[int, float]]: ...
def reflow(text: str) -> str: ...

load_library reads the cached .npy files off disk and hands back a list of Passage tuples plus the stacked matrix.

search_passages takes those two and a query and returns ranked (index, score) pairs.

The web layer consumes the core functions, no re-implementation:

from main import (
    embed,
    Passage,
    humanize_author,
    load_library,
    reflow,
    search_passages,
)

The CLI's ask() and the web app's /api/ask share the same spine: load the library, call search_passages, walk the ranked (index, score) pairs. From there each does its own thing. The CLI prints rich panels and offers an interactive deep-read; the web app serializes to Match JSON and logs a bit of analytics on the way out.

The ranking decision, what comes back and in what order, is shared. Everything downstream is presentation, which is exactly where a CLI and a web app should differ.

We do the same in our agentic AI program: one core engine, three interfaces (CLI, Telegram, API / web dashboard).

I needed caching

load_library is not cheap. It walks books/, reads a JSON file and an .npy file per book, and stacks 80k vectors into one matrix with np.vstack. You don't want to pay that overhead on every HTTP request!

In the CLI that's a non-issue: the process loads once and exits. On the web side, it's one decorator away:

from functools import cache

@cache
def library() -> tuple[list[Passage], np.ndarray]:
    return load_library()

@cache turns the first call into the real load and every call after into a dictionary lookup, much faster.

@app.get("/api/ask")
def ask(q: str, k: int = 5, per_book: int = 2, floor: float = 0.6) -> list[Match]:
    passages, vectors = library()  # cached
    ...

Pre-warm on startup, not on the first visitor

There's a subtlety @cache doesn't solve on its own. If the first request is what triggers library() ("wakes up PyTorch"), then the first real visitor pays that tax. App restarts are rare, but making the first visitor wait still isn't acceptable.

FastAPI's lifespan offers a nice fix for this: do it as soon as the app starts, before the first request:

@asynccontextmanager
async def lifespan(app: FastAPI):
    init_db()
    logger.info("Pre-warming vector library and loading models into RAM...")
    _ = library()          # fills the @cache with the stacked matrix
    _ = embed(["warmup"])   # forces PyTorch to wake up and allocate
    logger.info("Ready for traffic.")
    yield

app = FastAPI(title="classics", lifespan=lifespan)

I left a log line to watch the startup time. I also added some comments for possible collaborators and my future self.
I use _ as a throwaway variable to make it clear the return value is ignored.
You can put shutdown logic after yield, similar to how pytest fixtures work. Clean.

By the time the first request lands, both are warm.

Lazy loading

I am a proponent of imports at the top, but lazy loading is a serious performance consideration. It's coming in 3.15:

Lazy imports defer the loading and execution of a module until the first time the imported name is used, in contrast to ‘normal’ imports, which eagerly load and execute a module at the point of the import statement. - PEP 810 – Explicit lazy imports

That's the automatic version, landing in 3.15. Here I do it by hand: defer the model import into the function that needs it:

@cache
def _model():
    import sentence_transformers as st  # lazy, so the offline env vars take effect first
    return st.SentenceTransformer(EMBED_MODEL)

So the model loads once, and only if something actually calls _model(). @cache hands back the same instance every time after.

The "offline env vars" part refers to the second reason I need the import here. At the top of the module I have:

os.environ.setdefault("HF_HUB_OFFLINE", "1")
os.environ.setdefault("TRANSFORMERS_OFFLINE", "1")
os.environ.setdefault("TQDM_DISABLE", "1")

Hugging Face reads HF_HUB_OFFLINE at import time. Import sentence-transformers before those are set and it will try to reach out to the internet, which is not what I want because I have the data and model cached locally. Set them first and the model stays fully offline, no surprise network calls.

Functions vs classes

None of this needs a class. The core is functions over plain data (Passage and Chunk are NamedTuples), the only state is a memoized function, and the two interfaces are thin adapters that share common behavior.

That's the payoff. When I want a third interface tomorrow (e.g. a scheduled job or a different API), it imports the same functions and gets the same behavior for free.

Next up in part 3: the small post-processing tricks that make the results actually good, no bigger model required.

Armin Ronacher: Better Models: Worse Tools

Sat, 04 Jul 2026 00:00:00 +0000

A very strange Pi issue sent me down a rabbit hole over the last two days. The short version is that newer Claude models sometimes call Pi’s edit tool with extra, invented fields in the nested edits[] array. And not Haiku or some small model: Opus 4.8. The edit itself is usually correct but the arguments do not match the schema as the model invents made-up keys and Pi thus rejects the tool call and asks to try again.

That alone is not too surprising as models emit malformed tool calls sometimes. Particularly small ones. What surprised me is that this is getting worse with newer Anthropic models as both Opus 4.8 and Sonnet 5 show it but none of the older models. In other words, the SOTA models of the family are worse at this specific tool schema than their older siblings.

In case you are curious about Fable: I intentionally did not test it because I was not sure if the classifiers they are running might downgrade me to Opus silently.

Tool Calls Are Text

If you have not spent too much time looking at LLM tool calling internals, the important thing to understand is that tool calls are not magic and use some rather crude in-band signalling. The model receives a transcript, a system prompt and a list of available tools. The server munches that into a large prompt with special marker tokens. Because the model was trained and reinforced on examples of that format, at some point during generation it emits something that the API or client interprets as “call this tool with these arguments”.

For a file edit tool, the intended invocation payload might say something like this:

{
  "path": "some/file.py",
  "edits": [
    {
      "oldText": "text to replace",
      "newText": "replacement text"
    }
  ]
}

A harness then validates the arguments, performs the edit, and feeds the result back into the model. If validation fails, the model sees an error and usually tries again.

How exactly that formatting happens is not known for the Anthropic models, but some people have gotten out “ANTML” markers and they at times do leak also into public communications. To the best of my knowledge, the call above would come out serialized like this from the model:

<antml:function_calls>
  <antml:invoke name="edit">
    <antml:parameter name="path">some/file.py</antml:parameter>
    <antml:parameter name="edits">
[
  {
    "oldText": "text to replace",
    "newText": "replacement text"
  }
]
    </antml:parameter>
  </antml:invoke>
</antml:function_calls>

An important thing to note here is that this thing, while looking like XML, is not really XML. It’s just a thing they found convenient to tokenize and train on. The other thing to note is that a basic top-level string parameter appears in-line whereas an array of objects is implemented via JSON serialization. While I’m not entirely sure that this is how it works, there are some indications that this is not too far off. This will become relevant later.

There are two very different ways to make the model produce a structure like this:

You can ask the model to produce valid JSON matching a schema and then validate it afterwards.
You can constrain the sampler so that invalid JSON, or even invalid schema shapes, cannot be sampled in the first place.

The second approach is what people usually refer to as grammar-aware or constrained decoding. The sampler masks out tokens that would violate the grammar. If the model is currently inside a JSON object and the schema says only oldText and newText are allowed, the sampler can prevent it from emitting "in_file" or "type". Grammar-aware decoding can be used both to constrain something to be syntactically valid JSON and also to enforce specific enum values or keys.

Without any form of constraints the model is merely following a learned convention.

The Failure

Pi’s edit tool supports multiple exact string replacements in one call. That is why the arguments contain an edits array. In the failing cases the model produces entries like this:

{
  "oldText": "...",
  "newText": "...",
  "requireUnique": true
}

or this:

{
  "oldText": "...",
  "newText": "...",
  "oldText2": "",
  "newText2": ""
}

Across repeated trials I saw a whole zoo of invented trailing keys: type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2, and even an event.0.additionalProperties key inside the edit object itself.

The most annoying part is that the actual oldText and newText payloads were byte-correct in the invalid calls I inspected. The model had in fact produced the right invocation but then added nonsense at the end of the object.

The failure is also heavily context-dependent. A fresh single-turn prompt like “edit this file” did not reproduce it at all for me. An agentic history where the model had read files, diagnosed a problem and then composed a multi-line edit could reproduce it. And more annoyingly, not all transcripts will show that behavior. In fact, I needed Petr Baudis‘s transcripts to reproduce this for me at all! In that user’s session continuing the session caused Opus 4.8 to fail around 20% of the time. Stripping thinking blocks from history reduced the failure rate by half. Turning on strict tool invocation eliminated it in my runs.

Why It’s Getting Worse

My strongest hypothesis is that this is not random deterioration but a training artifact.

When older Anthropic models were trained, they were trained on some tools (some of which were documented). But that training did not yet have a user-shipped harness like Claude Code as the obvious target. Modern Anthropic models are most likely different because their post-training includes Claude Code or a harness that looks very similar. The model learns what a successful tool call looks like in that environment. It also learns what mistakes are tolerated by that environment.

Claude Code’s own tools are comparatively flat. The ordinary edit tool is not Pi’s nested edits[] shape; it is closer to file_path, old_string, new_string, and an optional flag (replace_all). Looking at Claude Code’s client is very instructive: it contains retry paths for malformed tool use, parameter aliases, type coercions, Unicode repairs and filtering of unknown keys. In other words, Anthropic’s own client appears to expect and accept a fair amount of slop and repairs it, mostly silently.

If reinforcement learning happens in a harness like that, or a simulation of one, then slightly malformed tool calls can still complete the task and receive reward. The harness fully absorbs the error and there is little gradient against inventing an alias, adding a stray field or using a nearby parameter name.

Worse, the model may become very strongly adapted to the canonical Claude Code edit tool shape. A different harness can present a tool with the same semantic intent but a different schema. Such a tool can increasingly be off-distribution. The better-trained model might actually fight you harder because its prior is stronger.

This is not too surprising, but it is a change from how this was a few months ago. When Opus 4.5 launched, it adapted to other edit tools exceptionally well. In fact, I was pretty convinced that we’re on a good path where the models are more likely to adapt to any sort of tool shape that comes around for as long as the instructions are good.

Now I’m somewhat worried about the track we’re on here. Alternative tool schemas might not just be unfamiliar. They might be implicitly punished by post-training that optimizes for one particular, forgiving tool ecology. And that ecology is not documented. While there is a text editor tool that is documented, you will see that this format is in fact not followed by Claude Code. What Claude Code does internally (which is a closed-source harness) is hidden from you.

The Slop Harness

Claude Code is obviously closed-source but we can look at the minified code and get some idea of what it does. And honestly, it’s very forgiving of incoming data.

For a start, Claude Code checks the model’s visible text for leaked <invoke markup. It also emits some telemetry when that happens and then it has its own state machine to retry such bad calls by pushing back to the model.

It has explicit Unicode escape repair which fixes broken \uXXXX sequences and lone surrogates in string values. It also has per-tool aliases for parameters. For instance, Edit accepts old_str (presumably from the times when the models were trained on the officially documented text editor tool), the newer old_string from the schema, new_str/new_string, path as an alias for file_path, and some more.

It also silently filters out unexpected keys and it does not use strict mode either. The issue with strict mode is that Anthropic applies complexity limits to the tool definitions that cause API requests to fail, so presumably that’s why Claude Code does not attempt to use it.

Strictness

Will this problem be with us in other harnesses too? One huge issue with Anthropic is that the models are completely closed, and so is the harness. Codex models are also closed, but at least the harness is not. We also have gpt-oss which is at least a bit interesting. The models are explicitly trained to use OpenAI’s harmony response format and there is a lot of documentation that at least tells us how OpenAI people think about this.

Harmony makes channels and tool-call content types part of the prompt format. A function call can look like this:

<|start|>assistant<|channel|>commentary to=functions.get_weather
<|constrain|>json<|message|>{"location":"San Francisco"}<|call|>

The important bit is <|constrain|>json. The model can express in-band that this message body is JSON, and an inference stack can use that boundary to switch into JSON-constrained sampling for the body of the tool call. Presumably a bit of this also happens in Anthropic’s models, at least in strict mode I would imagine.

The marker in harmony helps the sampler to detect when it needs to sample with a specific grammar, and because it is part of the transcript, it makes that rather easy to do. For hosted GPT models, there is also an option to provide a LARK grammar for custom tools that need to adhere to something like this.

Anthropic appears different from that, though maybe not entirely. If an array of objects is represented as JSON, as it appears to be, then the model has to write JSON inside the tool parameter. There is probably basic grammar-constrained sampling going on, and that may partly explain the extra keys. For a nested array parameter, that JSON includes escaped multi-line file content inside string literals, inside one tag. The unexpected, made-up keys appear exactly at the highest-entropy point of that task: after closing a several-hundred-token escaped newText string, where the model must decide } vs , "...".

Opus 4.8 and Sonnet 5 seem to have much stronger priors about what an edit tool call should look like and that prior appears to be Claude Code’s edit schema: a flat old/new string pair, plus the optional replace_all flag. My guess is that Opus has learned that an edit operation may have one extra optional field, but under Pi’s nested oldText/newText shape it has no trained name for that field. So it samples a plausible name fresh each time, which is why the failures produce dozens of random keys rather than one stable alias.

As strict mode in Anthropic appears to fix this, I presume that on the server side they are refusing to sample a key that is not permitted by the JSON schema structure. That would also explain why they have limits to the complexity of the tool definitions when strict mode is enabled.

So far, the Codex models I tested did not show this type of regression. I tested all available ones except 5.6, which I do not have access to yet.

What This Means For Harnesses

The uncomfortable lesson is that tool schemas are not neutral, at least not on Anthropic models. We like to pretend that a schema is an abstract contract and the model is a general reasoner that will follow it, but that might no longer be the case for some of the tools.

Tool schemas are somewhere in the distribution and some shapes are close to what the model saw during post-training and some are far away. Some are easy for the provider’s hidden encoding (e.g. top-level attributes in ANTML), whereas some require the model to write large escaped JSON objects inside nested arrays after long multiline strings. The model may be smart enough to understand the schema and still be bad at sampling the exact shape under pressure.

If this type of model behavior continues, I wonder what the implications for harnesses are. Obviously one could turn on strict sampling in Anthropic and the problem should go away. On the other hand, that the model has this behavior shows the impact that reinforcement learning has on them. Fighting that prior is probably futile if you want to get the best model performance.

Right now the reality is that Claude Code is not open source and we cannot really know what they are doing in their RL environments either. We cannot assume Claude-Code-trained behavior will transfer cleanly to your tools unless they are a close match. The more post-training happens inside one dominant harness, the more every other harness will have to inherit its quirks.

I used to be more skeptical of strict grammar-constrained tool invocation because constrained decoding can have quality tradeoffs. I still think that can be true in general, but this bug moved my priors significantly. If the newest models get better at solving the task while getting worse at faithfully emitting an alternative tool schema, then the harness needs stronger guarantees somewhere.

If you want to find out more, or you want to discuss this, consider reading the issue on the Pi tracker.

Mycli: Release v2.0.0

Fri, 03 Jul 2026 07:00:00 +0000

mycli is a command line interface for MySQL which includes auto-completion and syntax highlighting.

Read the install instructions to find out how to get the latest version.

Mycli v2.0.0 has breaking changes!

Major features added in recent months include

powerful fuzzy history search with fzf (thanks lazmond3!)
integrated …

Planet Python

EuroPython: Humans of EuroPython: Daria Linhart Grudzień

Python Software Foundation: The PSF D&I Workgroup Are Starting Office Hours in July!

The details

What will we talk about

No camera, no mic, no pressure

Bring your own language

See you on the 28th!

Django Weblog: Last Call 2026 Django Developer Survey

How you can help

Mike Driscoll: New Book Release: Python Typing

What You’ll Learn

Where to Purchase

Hugo van Kemenade: Fixing the dictionary with Python 3.14

Marc-André Lemburg: My 25th EuroPython - in a row😊

Python GUIs: Why Widgets Appear as Separate Windows — Understanding widget parenting in Qt and how to fix widgets that float outside your main window

How Qt decides what's a window

Three ways to Get a Parent-less Widget

Creating widgets without a parent

Accidentally recreating a widget

Losing the parent reference

A clean approach to dynamic tabs

Summary

Brett Cannon: How to publish to PyPI using GitHub Actions securely

Use zizmor

Make zizmor happy

No permissions by default

No persisted credentials after checkout

Pin your actions

Bonus: Dependabot to keep actions up-to-date

Add zizmor to CI

Use Trusted Publishing

Require approval to publish

Acknowledgments

PyCoder’s Weekly: Issue #742: Wagtail as Admin, Random Values, Code Quality, and More (2026-07-07)

Discussions

Articles & Tutorials

Projects & Code

Events

PyCharm: Best Object Detection Models for Machine Learning in 2026

What is object detection?

Object detection algorithms and architecture families

Architectures

CNN-based

Transformer-based

Processing flows

Two-stage detectors

Single-stage detectors

Top object detection models in 2026

RF-DETR (by Roboflow) – Highest Accuracy

YOLO12 (Tsinghua University) – Research / Benchmark

YOLO26 (Ultralytics) – Best for edge / production

Benchmark comparison

Use-case guidance

Licensing Summary

Quick-start code

RF-DETR

YOLO26 / YOLO12 (via Ultralytics)

YOLO12 (use original open-source repo – not the Ultralytics integration)

Transfer learning and fine-tuning

Summary: Choosing the right model for your project

Get started with PyCharm today

Ari Lamstein: This Thursday: Building Data Apps with Streamlit and Copilot

What we’ll cover

What You’ll Build

Who is this for?

How to Register

Django Weblog: Django security releases issued: 6.0.7 and 5.2.16

CVE-2026-48588: Potential exposure of private data via cached Set-Cookie response

CVE-2026-53877: Heap buffer over-read in GDALRaster

CVE-2026-53878: Header injection possibility since DomainNameValidator accepted newlines in input

Affected supported versions

Resolution

CVE-2026-48588: Potential exposure of private data via cached Set-Cookie response

CVE-2026-53877: Heap buffer over-read in GDALRaster

CVE-2026-53878: Header injection possibility since DomainNameValidator accepted newlines in input

The following releases have been issued

General notes regarding security reporting

PyCon: Welcome, Kattni!

Python Bytes: #487 Minimum requirements

CVE-2026-48588: Potential exposure of private data via cached `Set-Cookie` response

CVE-2026-53877: Heap buffer over-read in `GDALRaster`

CVE-2026-53878: Header injection possibility since `DomainNameValidator` accepted newlines in input

CVE-2026-48588: Potential exposure of private data via cached `Set-Cookie` response

CVE-2026-53877: Heap buffer over-read in `GDALRaster`

CVE-2026-53878: Header injection possibility since `DomainNameValidator` accepted newlines in input

1. `# type: ignore[code]` is not portable

3. pyrefly's `[[tool.pyrefly.sub-config]]` array-of-tables is fragile against interleaving

4. A `Protocol` is not assignable to a concrete class parameter

6. `**heterogeneous_dict` splats can't be validated against multi-parameter constructors

8. Fixing the root cause makes old workaround `cast()`s redundant — clean them up