Planet Python

eGenix.com: Python Meeting Düsseldorf - 2026-10-07

Tue, 29 Sep 2026 08:00:00 +0000

The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.

Ankündigung

Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:

07.10.2026, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Programm

Bereits angemeldete Vorträge

Philipp von dem Bussche:
Overengineering eines Fotobuchs: Meine Agenten-Reise durch Japans Sitzbezüge
Jens Diemer:
Radicle Explorer (LT)
Marc-André Lemburg:
Common shortcuts AI agents love to use
Jochen Wersdörfer:
AI coding harnesses
Klaus Bremer:
Monte Carlo Simulation und Concurrency mit Freethreading und Subinterpreters in Python 3.13 bis 3.15

Weitere Vorträge können gerne noch angemeldet werden. Bei Interesse, bitte unter info@pyddf.de melden.

Startzeit und Ort

Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden.

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.

>>> Eingang in Google Street View

⚠️ Wichtig: Bitte nur dann anmelden, wenn ihr absolut sicher seid, dass ihr auch kommt. Angesichts der begrenzten Anzahl Plätze, haben wir kein Verständnis für kurzfristige Absagen oder No-Shows.

Einleitung

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

Format

Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion.

Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit HDMI und FullHD Auflösung steht zur Verfügung.

(Lightning) Talk Anmeldung bitte formlos per EMail an info@pyddf.de

Kostenbeteiligung

Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.

Tagungsraum, Beamer und Getränke produzieren Kosten. Daher bitten wir die Teilnehmer um eine Kostenbeteiligung in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

Anmeldung

Da wir nur 25 Personen in dem angemieteten Raum empfangen können, möchten wir bitten, sich vorher anzumelden.

>>> Anmeldung bitte über den hierfür angelegten LinkedIn Event

Weitere Informationen

Weitere Informationen finden Sie auf der Webseite des Meetings:

https://pyddf.de/

Viel Spaß !

Marc-Andre Lemburg, eGenix.com

The Python Coding Stack: The Potion Shop That Does Too Much • The S in SOLID

Mon, 28 Sep 2026 17:17:11 +0000

The potion shop had been doing well.

It had a small but loyal customer base, a reliable supply of moonflower, and
three owls that carried order confirmations and other notifications to customers across the kingdom.

The shop’s ordering system was simple:

All code blocks are available in text format at the end of this article • #1

We’ll make significant changes to this code in this article, but bear with me for now.

A customer orders an invisibility potion:

The output looks good:

Invisibility  £12.00
Owl dispatched to Merlin
12.00

I’m using Decimal for the prices here as it’s a better data type for money than float. We discussed this a bit here, too: The Weird and Wonderful World of Descriptors in Python • The Price is Right.

The shop has sold a potion, updated its stock, recorded the sale, and notified the customer.

What could possibly go wrong?

A new label for the Moon Festival

The Moon Festival is approaching, and the shop owner wants special labels:

🌙 Moon Festival Invisibility 🌙   £12.00

We could change .sell():

You can read more about the ‘rogue asterisk’ in the signature, a.k.a keyword-only arguments, in this post: A Story About Parameters and Arguments in Python Functions • “AI Coffee” Grand Opening This Monday.

Now this works:

Here’s the output from this code:

🌙 Moon Festival Invisibility 🌙  £12.00
Owl dispatched to Merlin
12.00

The change is small. Perhaps this class is still perfectly fine.

The shop owner then asks for a test that checks the label without selling a potion. This is where you start to see the design problem.

At the moment, the only place that creates a label is inside .sell(). There is no suitable way to check the label policy independently. The code does not offer a way to ask for a label without also selling a potion.

The design problem is that PotionShop currently is in charge of label creation, even though the label policy can change independently of the policy that deals with sales. How about moving label creation to its own class?

Now you can check that the label is correct without having to sell an item in the first place:

This code would raise an AssertionError if the string that labels.make() returns is not identical to the required output. In this case, there are no errors.

In a real project, you could use a testing platform to run these checks. But I’ll use plain assert statements throughout to keep things simpler in this tutorial.

The shop delegates label-making to this object:

You should also remove the three lines that create a label you had further down within .sell().

We’re using composition here. The Potion Shop has a label maker, and you pass a LabelMaker object to the .label_maker attribute in the PotionShop object. The PotionShop object can now delegate label making to an object dedicated to this task.

From this point onwards, the shop receives the label-making collaborator:

PotionShop still coordinates the sale, but the label policy can now change without changing PotionShop. We started separating responsibilities. Making labels is no longer the responsibility of the PotionShop object. But we still have a bit more to go.

You got a taste of what the Single Responsibility Principle does in the example so far. But the code still has other transgressions of this principle. Let’s work through them in the rest of this post.

Coming soon: Let’s build a project from beginning to end in collaboration with AI agents. This will NOT be vibe coding. Instead, it’s a collaboration between knowledgeable humans and powerful AI.

This is the direction real programming is taking.

And we’ll explore SOLID principles in this project, which I’ll share as text and videos. Make sure you’re a premium subscriber so you don’t miss out.

Subscribe now

The owls go on strike

A few days later, the owls refuse to fly during a thunderstorm. The potions can still be prepared, but the notification service is unavailable.

The shop needs to stop sending notifications temporarily.

Before changing the notification system, we first make the owl’s availability explicit:

But you also want to add a test to check the price is correct.

Your code extracts the price from the .recipes class attribute as part of the .sell() method. So, this is how you can test the price is what you’re expecting:

#10

You get the following output and no AssertionError in this case:

Invisibility  £12.00
Owl dispatched to Merlin

However, you should also test this when the owls are unavailable. Of course, this shouldn’t make any difference to the price:

#11

But, your code doesn’t get that far. The .sell() method calculates the price and prints the label. But the owl service raises OwlUnavailable and the code stops before you can verify the price is right:

Invisibility  £12.00

Traceback (most recent call last):
  ...
OwlUnavailable: The owls are currently unavailable

The price is not the problem. The test cannot inspect the price without also triggering an owl notification.

The shop’s different jobs are now getting in each other’s way. But before we fix this problem, let’s make the mess bigger.

A discount for cauldron owners

The owner has another idea. Customers who bring their own cauldron should receive a 10% discount.

We add another parameter:

#12

You use .quantize(), which is a method in the Decimal class, to ensure the discounted value is rounded to two decimal places. Let’s try this with a shop whose notification service is available:

#13

The output shows the correct discounted price:

Invisibility  £10.80
Owl dispatched to Merlin
10.80

Let’s see what happens if the owls are unavailable:

#14

Your code raises an error since the owls aren’t flying:

Invisibility  £10.80
Traceback (most recent call last):
  ...
OwlUnavailable: The owls are currently unavailable

But there’s an even bigger problem now. Can you spot it?

Even though the code stopped execution and raised an error, it had already changed the stock and recorded a sale. Let’s use a try..except block to see what’s happening:

#15

Here’s the output:

Invisibility  £10.80
Catching the ‘OwlUnavailable’ Exception
{’moonflower’: 8, ‘dragon_scale’: 0}
[(’Merlin’, ‘invisibility’, Decimal(’10.80’))]

You started off with 10 units of moonflower and 2 units of dragon scales in the potion shop. These values are currently hardcoded in the class’s .__init__() special method (which is in itself not a good idea, but more on this later.)

The recipe uses two units of each, as shown in the .recipes class attribute (which will also change soon.)

So you end up using up the stock even though .sell() raised an exception! You can see from the output that the sale was also registered.

One failure too many

The .sell() method is now responsible for:

Looking up recipes
Removing ingredients
Calculating prices
Applying discounts
Coordinating label creation*
Recording sales
Sending notifications

* Creating labels is the one we have already improved. It’s the others that are still a problem!

And the owner has just mentioned loyalty points, premium labels, email notifications, and a special discount for customers who arrive by broomstick.

The .sell() method is becoming the place where every new request arrives.

And it’s not just PotionShop.sell() that’s trying to do too much. The PotionShop class also takes care of the recipes available in the .recipes class attribute and the stock available in the shop.

It is time to separate these responsibilities.

Separating the recipe book

Let’s start with the recipes. The shop should not need to know the details of every recipe. That is the recipe book’s job:

#16

This class is responsible for the recipe book. And nothing else. You add the .find() method to make it easier for a user to use the class without knowing the details of how it’s built. It’s usually best for a class to manage its own data. So, rather than requiring the user to know that the recipes are stored in a dictionary, you provide the .find() method that does the work.

Suppose the potion maker changes a recipe or adds a new potion. Those changes belong in RecipeBook; the steps for selling a potion don’t need to change.

We can test this class without creating a shop, changing stock, printing labels, or sending owls:

#17

This code doesn’t raise an exception since the price is correct.

Separating inventory

Inventory management also doesn’t belong to the PotionShop class:

#18

The two loops in .remove_stock() are deliberate. If we reduced each quantity as we went, we could use some ingredients and then discover that there isn’t enough of another. The sale would fail, but the stock would already be partly changed. Checking every quantity first avoids that partial update.

We can see what happens when there isn’t enough stock:

#19

The operation fails before changing any stock:

Not enough dragon_scale
{’moonflower’: 10, ‘dragon_scale’: 2}

After a successful sale, a delivery can add stock again:

#20

Here’s the output from this code:

{’moonflower’: 13, ‘dragon_scale’: 0}

Inventory owns both the stock data and the operations that change its quantities. It does not need to know who bought the potion or whether the label is festive.

Separating prices and labels

Pricing has its own rules:

#21

Once again, this class now has just one responsibility: to deal with the pricing.

#22

You can check the pricing strategy works without having to sell a product and everything else.

10.80

Labels have their own rules too. You dealt with this earlier in the tutorial when you created LabelMaker

PriceCalculator and LabelMaker could both be functions here. We’re using classes because they act as collaborators that the shop receives from outside. Later, we’ll see how protocols or abstract base classes can describe interchangeable collaborators more explicitly. For now, the important point is the separation of responsibilities and not the fact that each responsibility has become a class.

Neither class needs an inventory, a sales ledger, or an owl.

Putting the shop back together

We still need something to coordinate the sale. First, we give the sales ledger and the notifier small, focused interfaces:

#23

Notice the "pending" state in the ledger. Separating responsibilities does not make the sale process independent of anything else. Inventory has already changed before later steps run. Here, the narrower goal is to make notification failure visible so that the recorded sale can be investigated.

Now we can keep PotionShop as a thin coordinator. It still represents the sale process, but it delegates each part of that process to the object that owns the relevant behaviour:

#24

We can now assemble the shop and sell a potion:

#25

Here’s the output:

🌙 Moon Festival Invisibility 🌙 £10.80
Owl dispatched to Merlin
10.80
{’customer’: ‘Merlin’, ‘potion’: ‘invisibility’, ‘price’: Decimal(’10.80’), ‘notification’: ‘sent’}

If notification fails after the ledger records the sale, the sale remains
visible with a pending notification:

#26

Here’s the output:

Invisibility  £12.00
{’customer’: ‘Merlin’, ‘potion’: ‘invisibility’, 
 ‘price’: Decimal(’12.00’), ‘notification’: ‘pending’}

The coordinator still changes if the business process changes. That’s fine: coordinating a sale is its responsibility. But recipe changes belong in RecipeBook, inventory changes belong in Inventory, pricing changes belong in PriceCalculator, label changes belong in LabelMaker, and notification changes belong in Notifier.

The Single Responsibility Principle

This is the idea behind the Single Responsibility Principle:

A class should have one reason to change.

I always find these “official” definitions a bit cryptic when I read them at first. Here, “reason” is about the policy or stakeholder driving the change. The pricing rules may change because the shop owner changes the discounts. The label design may change because the person responsible for packaging wants something different. The notification service may change because the owls are on strike.

That does not mean that every class should have one method. Nor does it mean that every noun in the story needs its own class.

PriceCalculator can have several related methods. Inventory can have several operations. The important question is whether the methods belong to the same coherent responsibility.

The thin PotionShop coordinator is also a class with a responsibility. It coordinates the sale. A change to that business process may quite reasonably affect it.

When unrelated changes keep arriving at the same class, the class becomes harder to test and more likely to break. Extract a collaborator when it may need to change for a different reason from the surrounding code, or when separating it makes an important test simpler. A good class name alone isn’t a reason to create one.

The potion shop did not become troublesome because it had a particular number of lines. It became troublesome because recipes, inventory, pricing, labels, sales, and notifications all had different reasons to change.

A useful question to ask is:

What different kinds of change could affect this class?

If the answers are “the pricing rules”, “the label design”, “the storage system”, and “the notification service”, you may have several responsibilities sharing one home.

And if the project keeps growing, we may need to rethink the floor plan.

This is the first article in a series on the SOLID principles. I’ll look at what each principle means, but more importantly, why it matters and what can go wrong when we ignore it.

Code in this article uses Python 3.14.

Do you want to keep up with how Python programming and the art of making things are changing in this rapidly changing world? Then don’t miss out on the exclusive content for premium members here on The Python Coding Stack.

Subscribe now

I’ll be sharing more about how my programming, my daily work, and everything has changed over the recent months.

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

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

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

Appendix: Code Blocks

Code Block #1

from decimal import Decimal

class PotionShop:
    recipes = {
        “invisibility”: {
            “ingredients”: {
                “moonflower”: 2,
                “dragon_scale”: 2,
            },
            “price”: Decimal(”12.00”),
        }
    }

    def __init__(self):
        self.stock = {
            “moonflower”: 10,
            “dragon_scale”: 2,
        }
        self.sales = []

    def sell(self, potion_name, customer):
        potion = self.recipes[potion_name]

        for ingredient, quantity in potion[”ingredients”].items():
            if self.stock[ingredient] < quantity:
                raise ValueError(f”Not enough {ingredient}”)

        for ingredient, quantity in potion[”ingredients”].items():
            self.stock[ingredient] -= quantity

        price = potion[”price”]
        self.sales.append((customer, potion_name, price))

        print(f”{potion_name.title()}\t£{price:.2f}”)
        self.send_owl(
            customer,
            {”potion_name”: potion_name, “price”: price},
        )

        return price

    def send_owl(self, customer, message_content):
        print(f”Owl dispatched to {customer}”)
        return message_content

Code Block #2

shop = PotionShop()
print(shop.sell(”invisibility”, “Merlin”))

Code Block #3

# ...

class PotionShop:
    # ...

    def sell(
            self,
            potion_name,
            customer,
            *,
            moon_festival=False,
    ):
        # ...

        label = potion_name.title()
        if moon_festival:
            label = f”🌙 Moon Festival {label} 🌙”

        print(f”{label}\t£{price:.2f}”)

        # ...
    # ...

Code Block #4

shop = PotionShop()
print(shop.sell(”invisibility”, “Merlin”, moon_festival=True))

Code Block #5

# ...

class LabelMaker:
    def make(self, potion_name, moon_festival=False):
        label = potion_name.title()

        if moon_festival:
            label = f”🌙 Moon Festival {label} 🌙”

        return label

# ...

Code Block #6

labels = LabelMaker()
assert labels.make(
    “invisibility”,
    moon_festival=True,
) == “🌙 Moon Festival Invisibility 🌙”

Code Block #7

# ...

class PotionShop:
    # ...

    def __init__(self, label_maker):
        self.label_maker = label_maker
        # ...

    def sell(
            self,
            potion_name,
            customer,
            *,
            moon_festival=False,
    ):
        # ...
        label = self.label_maker.make(
            potion_name,
            moon_festival=moon_festival,
        )
        # ...

    # ...

Code Block #8

shop = PotionShop(LabelMaker())

Code Block #9

# ...

class OwlUnavailable(Exception):
    pass

# ...

class PotionShop:
    # ...

    def __init__(self, label_maker, owl_available=True):
        self.label_maker = label_maker
        self.owl_available = owl_available
        # ...

    # ...

    def send_owl(self, customer, message_content):
        if not self.owl_available:
            raise OwlUnavailable(
                “The owls are currently unavailable”
            )
        print(f”Owl dispatched to {customer}”)
        return message_content

Code Block #10

shop = PotionShop(LabelMaker())

assert shop.sell(”invisibility”, “Merlin”) == Decimal(”12.00”)

Code Block #11

shop = PotionShop(LabelMaker(), owl_available=False)

assert shop.sell(”invisibility”, “Merlin”) == Decimal(”12.00”)

Code Block #12

class PotionShop:
    # ...

    def sell(
        self,
        potion_name,
        customer,
        *,
        moon_festival=False,
        own_cauldron=False,
    ):
        # ...

        price = potion[”price”]

        if own_cauldron:
            price = (price * Decimal(”0.90”)).quantize(Decimal(”0.01”))

        # ...

        return price

    # ...

Code Block #13

shop = PotionShop(LabelMaker())
print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        own_cauldron=True,
    )
)

Code Block #14

shop = PotionShop(LabelMaker(), owl_available=False)
print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        own_cauldron=True,
    )
)

Code Block #15

shop = PotionShop(LabelMaker(), owl_available=False)
try:
    print(
        shop.sell(
            “invisibility”,
            “Merlin”,
            own_cauldron=True,
        )
    )
except OwlUnavailable:
    print(”Catching the ‘OwlUnavailable’ Exception”)
    print(shop.stock)
    print(shop.sales)

Code Block #16

class RecipeBook:
    def __init__(self):
        self.recipes = {
            “invisibility”: {
                “ingredients”: {
                    “moonflower”: 2,
                    “dragon_scale”: 2,
                },
                “price”: Decimal(”12.00”),
            }
        }

    def find(self, potion_name):
        return self.recipes[potion_name]

Code Block #17

recipe_book = RecipeBook()
assert recipe_book.find(”invisibility”)[”price”] == Decimal(”12.00”)

Code Block #18

class Inventory:
    def __init__(self, stock):
        self.stock = stock

    def remove_stock(self, ingredients):
        for ingredient, quantity in ingredients.items():
            if self.stock[ingredient] < quantity:
                raise ValueError(f”Not enough {ingredient}”)

        for ingredient, quantity in ingredients.items():
            self.stock[ingredient] -= quantity

    def add_stock(self, ingredients):
        for ingredient, quantity in ingredients.items():
            self.stock[ingredient] = self.stock.get(ingredient, 0) + quantity

Code Block #19

inventory = Inventory({
    “moonflower”: 10,
    “dragon_scale”: 2,
})

try:
    inventory.remove_stock({
        “moonflower”: 2,
        “dragon_scale”: 3,
    })
except ValueError as error:
    print(error)

print(inventory.stock)

Code Block #20

inventory.remove_stock({
    “moonflower”: 2,
    “dragon_scale”: 2,
})
inventory.add_stock({”moonflower”: 5})
print(inventory.stock)

Code Block #21

class PriceCalculator:
    def calculate(self, recipe, own_cauldron=False):
        price = recipe[”price”]

        if own_cauldron:
            price = (
                price * Decimal(”0.90”)
            ).quantize(Decimal(”0.01”))

        return price

Code Block #22

pricing = PriceCalculator()
print(
    pricing.calculate(
        {”price”: Decimal(”12.00”)},
        own_cauldron=True,
    )
)

Code Block #23

class SalesLedger:
    def __init__(self):
        self.sales = []

    def record(self, customer, potion_name, price):
        sale = {
            “customer”: customer,
            “potion”: potion_name,
            “price”: price,
            “notification”: “pending”,
        }
        self.sales.append(sale)
        return sale

    def mark_notified(self, sale):
        sale[”notification”] = “sent”

class Notifier:
    def send(self, customer, potion_name, price):
        print(f”Owl dispatched to {customer}”)

Code Block #24

class PotionShop:
    def __init__(
        self,
        recipe_book,
        inventory,
        pricing,
        labels,
        ledger,
        notifier,
    ):
        self.recipe_book = recipe_book
        self.inventory = inventory
        self.pricing = pricing
        self.labels = labels
        self.ledger = ledger
        self.notifier = notifier

    def sell(self, potion_name, customer, *, moon_festival=False,
             own_cauldron=False):
        recipe = self.recipe_book.find(potion_name)
        self.inventory.remove_stock(recipe[”ingredients”])

        price = self.pricing.calculate(
            recipe,
            own_cauldron=own_cauldron,
        )
        label = self.labels.make(
            potion_name,
            moon_festival=moon_festival,
        )
        sale = self.ledger.record(customer, potion_name, price)

        print(f”{label}\t£{price:.2f}”)
        self.notifier.send(customer, potion_name, price)
        self.ledger.mark_notified(sale)

        return price

Code Block #25

ledger = SalesLedger()
shop = PotionShop(
    RecipeBook(),
    Inventory({”moonflower”: 10, “dragon_scale”: 2}),
    PriceCalculator(),
    LabelMaker(),
    ledger,
    Notifier(),
)

print(
    shop.sell(
        “invisibility”,
        “Merlin”,
        moon_festival=True,
        own_cauldron=True,
    )
)

assert ledger.sales[0][”notification”] == “sent”
print(ledger.sales[0])

Code Block #26

class FailingNotifier:
    def send(self, customer, potion_name, price):
        raise OwlUnavailable(”The owls are currently unavailable”)

ledger = SalesLedger()
shop = PotionShop(
    RecipeBook(),
    Inventory({”moonflower”: 10, “dragon_scale”: 2}),
    PriceCalculator(),
    LabelMaker(),
    ledger,
    FailingNotifier(),
)

try:
    shop.sell(”invisibility”, “Merlin”)
except OwlUnavailable:
    pass

print(ledger.sales[0])
assert ledger.sales[0][”notification”] == “pending”

stephengruppetta.com

Glyph Lefkowitz: What Would A Serious AI Product Look Like?

Mon, 28 Sep 2026 04:27:00 +0000

One of the issues that I have with the current generation of “AI” products is that they do not appear to take their own premises seriously. I look at a plethora of obsequious chatbots claiming to be serious tools for problem solving, and I think, this is not what a problem-solving tool would look like.

Even before we get to the tremendous ethical problems with the frontier labs, it is this impression of their composition as a product that makes me feel, constantly, whenever I am interacting with them, that they are less a software product than that they are a grift, a scam designed to make me feel like I am interacting with a product that has capabilities that it simply does not, to try to lull me into a false sense of security that I can trust it.

The frontier labs are of course the worst offenders, but every criticism here applies just as much to Ollama, which (if anything, due to the obviously poorer quality of the available models themselves) needs these features even more than the frontier labs do.

Here, I will set down a few features that might convince me that an LLM-based product, particularly one focused on research or software development, was actually serious about helping me do useful things with it.

Make “Checking For Mistakes” A First-Class Feature

This is the biggest issue, and the major reason that I was inspired to write this post.

It is a truth universally acknowledged, that AIs cannot reliably provide information.

I could cite a ton of news articles and studies about this fact, but there is no need. Every single chatbot admits this, up front, in a fine-print disclaimer as a core part of their user interface. Gemini says “AI can make mistakes, so double-check responses”, Claude says “Claude is AI and can make mistakes. Please double-check responses.¹” ChatGPT says “ChatGPT can make mistakes. Check important info.”.

Every time I see that last one, I wonder how I’m supposed to know what “info” is supposed to be “important”.

All of these warnings are all small, gray text, painfully obviously included as legalese to push responsibility back onto the user rather than to help with anything. This is a core limitation of all these products. Checking their output is a part of the workflow for using them that:

you absolutely cannot skip or skimp on without creating risks to yourself and whoever you are conveying its output to, and,
it is very easy to skip or skimp on and you are encouraged at every turn to do so, because “just trust the output” is one of the quickest ways to save time.

A chatbot product that took this weakness seriously, as an actual consideration for using it, would put a checkbox next to every claim in its output. It would be a 2-column worksheet, where you’ve got the LLM output in the first column, and next to it, human notes in the second column, explaining what work went into checking this claim, and a big checkbox that you would only check off after you believe you’d checked its claims thoroughly enough.

Coding assistants would need to have some version of this as well. Right now, this is pushed off into code review, which means it is a dark pattern which subtly encourages the “author”² to offload this work to their code reviewer without ever looking. Once again, “it’s probably fine, I don’t need to check” is the quickest way to save time and churn out those PRs faster.

It might even be useful for coding harnesses to have some affordance for checking code before it even runs tests. As the vendors themselves have admitted, it’s not just expensive to burn tokens on your “AI”, you also end up burning far more compute on the AI. Being able to check your diffs before sending them over to uselessly exhaust your testing compute cluster would be useful.

If your product tells me that it makes mistakes and I must be the one to check for the mistakes, but then gives me zero tools to check for mistakes, I cannot take it seriously.

More Citations to Check, And More Details

Most chatbots prefer to give an answer, rather than a citation. In my own personal use, I find that when asked to provide a list of citations with clearly marked sources for each one, they will appear to “get bored” halfway through the list and simply stop including citations at some point.

When the bots include citations at all, present them as inline annotations that say nothing but the domain name of the search result, in a font so small that it’s barely legible, and an equally indecipherable icon that is fewer than 16 pixels on a side.

This is backwards.

Now, I am aware that these citations do come from somewhere, and in an attempt to reduce hallucinations, all of the major providers support some form of “grounding”³, and that those little barely-readable citation links are referencing actual structures in the RAG pipeline and not just potentially-hallucinated tokens, but I’m not talking about the underlying machinery in the model, I’m talking about the presentation to the user.

Plus, regardless of whether a snippet of text came from a RAG query, we know that LLMs can never provide an authoritative result; it’s a fundamental limitation of the technology. They can still garble the results of RAG as much as they can misrepresent any other training data. This means that it must never present its results as authoritative.

If you ask an AI to do research queries, every result should be presented as a list of citations. Moreover, the presentation should display each citation as a large object of in its own right, with clearly identified metadata, including not just the site where it was found but its publication date and, if possible, the name of the author. The literal, unmodified quotation (not from RAG, not a summary: a quotation extracted with a regular program and not an LLM) should be front-and-center, larger than any AI-generated text.

If the AI product wants to editorialize or summarize (which should not always be necessary!), the AI-generated text should be presented as small text underneath the citation that has been found, de-emphasized as much as the disclaimer is right now, at the very least until the user has verified that the summary is accurate. Perhaps, for a research project, a “did you read the citation” checkbox might even be helpful.

If your product openly tells me that it will scramble, misrepresent, or omit its citations in its summaries, and I must read the original human-authored citations to be sure, but then gives me no tools to track my reading of those citations or even any way to find them, I cannot take it seriously.

No First-Person Output, No Apologies

There is no reason for a software development or research tool to use first-person language to describe itself. They should not do so. In fact they should not be allowed to do so.

There is also no reason that they should ever apologize. It is a waste of everyone’s time; it’s a waste for the chatbot to generate the apology, it’s a waste for the user to read the apology, and it’s a waste for the user to respond to the apology. Yet they unfailingly do this upon every correction.

The vendors of these tools know that they are routinely causing mental-health crises. In response, they have added non-functional “guard rails” that can still, in 2026, easily be bypassed.⁴

A product seriously interested in helping with productivity would correct this glaringly obvious flaw, focus on the task at hand, and stop emitting useless verbiage.

In the previous two sections, I tried to focus on ways in which the harness would be constructed differently even if the LLM technology is fundamentally impossible to improve; in this case, I have to assume that the labs have some control over the model itself. But unless they are truly incapable of influencing their output (and all their “benchmarks” and “capabilities” seem to indicate that they can control it very tightly) they ought to be building models that are much less verbose.

More Non-Natural-Language User Interfaces

Although natural language could hypothetically be a powerful interface for interacting with a computer system, the practical upshot of LLM natural language interfaces is that these interfaces are imprecise and repetitive, full of superstitions masquerading as “best practices”. The inputs are a mess and the resulting outputs are a mess.

The general way of addressing this unstructured mess is to allow the chatbot to directly take action in response to the user’s input; in other words to supply it with “tools” via an MCP server. But again, this is backwards. If we cannot even express our intent clearly in the first place, why are we trusting this system to take potentially destructive and harmful actions on our behalf?

Instead, I would expect a product that was seriously invested in helping me accomplish specific tasks, to have user interfaces specific to those tasks. Is it supposed to be able to be a security scanner that can discover OWASP top 10 bugs in a codebase? Have a button for that. Build that functionality into your harness, train it directly into the model, use smaller models that can satisfy that functionality more effectively than throwing it at the planet-sized brain of Fable or whatever.

I’m aware that there are small software startups that do something like this, but they are bolted on to the side of the main model providers’ APIs, not integrated into the core of the product and not using their own models and AI systems to achieve consistent and repeatable results.

Strong Data Provenance Indicators

Chatbots produce data tables pulled from websites, from APIs, from MCP tools or from summarizing and scrambling the user’s input. In order to provide the illusion of a seamless interface, this data is presented in-line regardless of where it comes from. But some of these outputs are produced mechanically via regular old API calls, for example, from the result of calling a tool or querying a website, but presented uniformly.

But there is a huge difference between an authoritative data source being inlined as part of a chatbot conversation, being treated as input by the chatbot, and some ad-hoc hallucinated data being treated as output of the chatbot.

If a product is trying to help me make accurate, empirically-grounded, data-driven decisions, the source of the data is critical.

Integrated into the “check for mistakes” and “verify citations” workflow I described above, there’s a necessary “verify data programmatically” pass as well; to have tools that will treat portions of the output as a regular spreadsheet, allowing regular-old computer arithmetic to verify things and showing where such arithmetic was used, and how.

Better User Control of Reproducibility

Anyone familiar with the technical specifics of LLMs will know that they have a variable called “temperature” which controls the degree of randomness that the LLM uses to produce its outputs. But most users don’t know this, because it isn’t exposed as part of the user interface by default.

This leads to a subjective impression that you asked ChatGPT, and you got ChatGPT’s authoritative answer.

You can’t just set the temperature to zero and still get useful results - I am aware that it does more than just scramble the output at random, and there are perhaps good reasons that simply exposing just a temperature setting would not be that useful to users. But if we followed some more of my earlier recommendations for making more structured UI elements to solve specific problems rather than having long back-and-forth chats where each refinement depends on the previous response, perhaps those elements could also re-play the process so that users can see how reliable the bot is at a particular task and develop a sense of how the stochastic nature of the process actually affects it.

Similarly, if a user is trying to solve the same problem repeatedly with a chatbot, and the chatbot product has numerous computational tools that don’t really have anything to do with the LLM, such as deterministic data-processing tools, then having a way to freeze the non-deterministic parts of the transcript but re-populate a particular data frame with updated information and fork / continue the conversation from there would be a way to avoid introducing pointless additional randomness when you already know what tool you’re trying to use.

The fact that every conversation is presented as this flat chat prompt that doesn’t let me interact with any of the widgets that were previously produced except through more chatting, really makes me feel like the whole product is just doing predatory social-media style “increase time on site” optimization, just trying to lure me into further repetitive and unreliable chats, rather than letting me get in, solve my problem, and get out.

Context Visibility

Managing the LLM context is the ongoing challenge facing organizations that are trying to use “agentic” workflows. Filling up the context with too much information causes well-known problems. In response, advanced LLM users attempting to solve larger problems must break up very long prompts into “skills”, give access to lengthy information via “tools”, and delegating sub-problems to “sub-agents” rather than simply extending a single prompt indefinitely.

All of these strategies have flaws, because even on the largest models, compared to the breadth and depth of knowledge-work problems, LLM contexts are quite small.

And yet, none of these products will show the context to the user by default. There are third-party addons that can show you a simple progress bar but for addressing the premier engineering difficulty with this technology, that is below the bare minimum.

This lack of visibility means that almost all of the tools for extending the context are flying blind. Rather than responding meaningfully to a full context, everyone just kind of guesses how much state they need by guessing and trying over and over again with progressively more elaborate skill and sub-agent layouts. Even managing context compaction ends up being an advanced API-driven workflow⁵.

A serious product that was trying to help the user understand would not only show “available context” but explain the impact of context compactions, make it easier to see harness-generated prompts, and so on. This would be a first-class feature, combined with the aforementioned reproducibility / replay tools, would allow users to do real experiments to develop an understanding about how to make good use of the context window.

A Sandbox That Actually Works

I’ve been focused on the chatbot interface here because it is the most immediately egregious upon looking at the UI. But the “agentic loop” tools used for coding are equally dangerous, if not more so. Coding tools keep destroying everyone’s data, over the course of years.

These catastrophic incidents that become front-page news are relatively rare compared to the amount of coding-agent use out there. But they also aren’t the only kind of sandbox violation. Coding models will so routinely edit test code instead of the system under test that there are “pro tips” articles all over the web giving you the flawed advice to simply ask the agent not to cheat. News write-ups of the catastrophic incidents themselves will also offer glib and wrong advice, like “use a docker container”. That might prevent it from literally deleting your operating system, but it won’t prevent it from destroying all the local work you have in your codebase (it needs access to a checkout, after all!)

There is a flurry of activity in the infosec space where people are rushing to plug the gaps left by these coding harnesses. Everyone’s got their own version of an MCP approval gateway where you can optionally place a proxy between your agent and your production infrastructure.

In the best case, though, all these mitigations and proxies and prompts simply turn the user into an auto-approval automaton, hitting Y, Y, Y, Y over and over again, until you finally are driven mad and hit “yes to all”, turn on full-auto mode and submit yourself to the void. With nothing between your personal vigilance and disaster, there are no workflows left beyond decrementing your own vigilance until there’s nothing left and then hoping the disaster never arrives.

The fact that some mitigations exist that can be deployed by extra-cautious users does not change the fact that “agentic coding” is an unsafe-by-default technology deployed without concern or guidance. Every frontier lab has tied a spring-loaded shotgun to a dog; the fact that dog owners can publish thoughtful blog posts explaining how you can teach your dog the basics of gun safety or how you can have your dogs play in a bullet-proof room does not mitigate the fact that the product should not have been allowed in the first place, nor should it continue to exist without VERY strong security controls.

I might believe that a frontier lab were seriously interested in providing developers with a useful tool if they shipped something that had safety built-in.

That means tools in the harness, detached from any LLM, independent of the prompt, that could:

sandbox all filesystem operations and strictly limit ANY deletions outside of specified scopes, regardless of operating system,
enforce snapshotting of the entire repo on every operation for easy rollbacks and minimal lost work,
remove the disaster of “auto mode” (not to mention nonsense like --dangerously-skip-permissions) entirely, and
carefully consider a structure for presenting plans to the user where, rather than provoking immediate alert fatigue by asking for checks on every action, make structured plans which can be submitted to the user as a group of actions and reviewed and approved as a batch.

In the same way that I suggested above that research-based tasks should have a way of re-issuing prompts to determine how reproducible a result is, or whether other sources might be found, agent-based tasks should have a way of being executed against mock services for popular APIs, so that the verification can match both on the front-end (review the plan for making the API calls before they’re executed) and the back end (review the API calls that were issued to the mock service and verify that they matched).

Instead, the frontier labs provide us products that are disasters out of the box, give us “best practices” to build massive and elaborate, as well as incomplete and error-prone, security perimeters of our own design. Then they blame “operator error” when it inevitably goes wrong. I cannot believe that these design choices are intended to help us be productive.

Bonus: Human Processes

Organizations deploying AI also frequently come across as unserious, for similar reasons. In 2023, naive exuberance could perhaps be forgiven. But today, as we near the close of 2026, there are several well-known problems, that have been extremely well-covered in the press. None of these things should be surprising, but most orgs deploying these tools are still just letting them rip and hoping it all works out.

Organizations deploying these tools would need at least three kinds of major modifications to their internal processes, if they wanted to be serious about using them safely:

1. Shift Rotations to Prevent Vigilance Decrement

There have been several high-profile incidents where software developers’ gradual acquiescence to accepting LLM output have lead to serious economic consequences for the companies deploying them, perhaps best typified by Amazon’s “millions of lost orders” due to a gradual decay of their engineering processes from LLM use.

These outages, and other AI-related failures, are due to the difficulty of maintaining focus on the same problems. In other words, as I described above, vigilance decrement is a constant problem, because AI outputs are most often correct, but continue to be incorrect in surprising and non-intuitive ways. As I have previously written, you cannot trust yourself to catch every bug with code review, and LLM output.

Aviation, for example, has very strict rules around rest requirements. There is also a specific rule that “No certificate holder may operate an aircraft without a second in command if that aircraft has a passenger seating configuration, excluding any pilot seat, of ten seats or more.”. Other safety-critical professions have similar rules.

And yet, even in the age of the supposed “AI revolution”, most software teams are still assigning every engineer a full feature load, not planning for any rest, and telling people to review code whenever they happen to have some “free time”.

Maintenance of vigilance has to be your top priority. Regular, scheduled, inviolable rest periods where people do work without AI assistance, and are not exposed to any AI output for review or otherwise, would be crucial in order to stay mentally sharp enough.

The tools themselves should have this sort of thing built in. The mistake-review process described above should have a periodic spot-check mode where a second reviewer periodically reviews a chatbot log, doing their own independent verification of claims, to see if they spot the same errors. This could provide a feedback loop to determine how much rest is necessary to maintain continuous attention and actually spot hallucinations.

2. Skill Practice To Prevent Skill Loss

It is also well-known that AI use leads to AI reliance, and AI reliance leads to skill loss.

I like to use the analogy to dockworkers at a seaport⁶ adopting automation.

If you employ dockworkers to load and unload ships all day long, they are going to be getting tons of exercise. They will be able to lift heavy objects on demand, whenever. They might have plenty of health problems and injuries from this type of work, but “lack of exercise” will not be a problem.

With the development of standardized container ships and mechanized cranes, you are going to be changing their job description substantially: now they mostly spend all day sitting in a small cubicle moving a control lever back and forth, not lifting heavy stuff. They will get worse at lifting heavy objects.

In this analogy however, the cranes are not all that reliable. We know they break, and they drop their payloads sometimes, and the stuff needs to be manually moved. But this only happens a few times a week, at most. If you need whoever is driving the crane to be able to jump out at any moment and still move stuff around manually, then you need to make an affordance for that. You need to give them time to go to the gym and do some lifting for practice, or every crane failure is going to be a major emergency.

An organization doing an AI transformation would also need a massive increase to learning & development budget, both in terms of resources and in terms of schedule. If your people are going to lose skills because they’ve lost regular practice in the incidental course of doing their duties, then they are going to need deliberate, intentional, non-incidental practice of those skills to keep them sharp.

But rather than trying to accommodate new workflows and give time for people to adjust, most AI mandates are simply dropped on workers like a ton of bricks, with no time to adapt and no affordance for maintaining their skills. Operate the crane and stay fit and healthy and ready to switch back to manual lifting at any time and then get back in the crane cockpit right afterwards. Don’t mess up.

Then an accident happens and everyone is surprised, as if this process weren’t practically designed to produce a terrible result.

3. Mental Health Resources to Deal with Mental Health Risks

AI psychosis often begins with practical problem-solving, and beyond that, it can start specifically at work. Not to mention the more pedestrian condition of “AI brain fry”.

If you are mandating your employees to use a hazardous tool that may seriously and directly damage their mental health, you need trainings and resources. You need in-house therapists and you need to be making sure to check in with people actively to make sure that this is not happening.

Again, the tool itself ought to have some way of dealing with this. An occasional “take a break” popup is easily dismissed; they need a user-visible AI personal dosimeter so you can see your cumulative usage over time.

I don’t even know if “usage over time” is a sufficient metric to gauge risk. Maybe if your work chatbot start to talk about resonance too much, unless you literally work as an acoustic engineer, that should be flagged for someone.

We are, again, years into dealing with these tools, and we know these risks exist. Yet no serious mitigations are provided. Not even any way of measuring the risk exposure.

And More

There are also many other risks associated with the technology. There are intellectual property risks with the foundation models, due to recklessness with their training data. There are existential financial risks associated with the infrastructure build-out. The extent to which most “open” models are simply derivatives of frontier models is an open question.

What I Think

If any one of these things were regularly overlooked by AI vendors or users, that would be a totally normal product oversight. Room for improvement for the next version, but nothing catastrophic.

Shipping without any of them doesn’t seem like lean product management, it seems like a careless attitude towards risk and a product design philosophy oriented entirely towards short-term demos, with no regard for how to realize actual productivity gains.

Furthermore, being available for years without anything like these features, despite hundreds of incidents demonstrating the risks, with hundreds of billions of dollars of funding, makes it seem to me like if they were to add all the features that would make their product actually safe and hypothetically useful, these features would reveal that it is actually not an improvement to productivity.

In the year since I first wrote about measuring the cost/benefit ratio of AI, I have heard from numerous people who have shown this to management to try to illustrate why their AI initiatives — like almost all AI initiatives — were either failing or burning out their engineers.

I’ve also heard from lots of people that have told me that it’s obviously useful and they don’t need to measure so carefully, because they are getting lots of work done that they couldn’t have otherwise.⁷

I have yet to hear from a single person who has said “yeah, we measured according to your methodology⁸, and it turns out that our AI work is going great and that our ratio is 0.75”.

Obviously, I cannot say for sure why this is; absence of evidence is not evidence of absence. But at this point I think the null hypothesis is that AI tools provide, in aggregate, zero value. They make mistakes too often, and the externalities they produce are so bad and so difficult to control that even before we get to the places where they are just physically poisoning people, even the negative effects on their direct users end up cancelling out whatever benefit to they provide to their organizations.

If I were wrong, then including tools to measure an AI’s effectiveness at the tasks their users are actually trying to accomplish, rather than meaningless benchmarks, would show big productivity gains. The frontier labs would be champing at the bit to add such features, and crowing about their fantastic results.

I think the labs know that if they did that, it would present a grim picture to their users. Such tools would let their users see that it’s making mistakes much more often than they realized, that they’re spending much more time with it than they want to be, and that it’s just generally not fit for purpose.

If they prove me wrong by adding in all of these safety mechanisms, and in the process, they make all of their AI technology less harmful, I’ll be thrilled to be debunked.

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you’ve read here and you’d like to read more of it, or you’d like to support my various open-source endeavors, you can support my work as a sponsor!

It is also interesting that for the next section, sometimes it seems that Claude’s disclaimer is “Please double-check cited sources.” instead. ↩
... by which I mean the “prompter”, since authorship is not what’s happening here. ↩
Claude has the “citations API”, Google has various different kinds of “grounding” against its own APIs, and I guess Microsoft can check OpenAI’s homework if you want. ↩
Given the relatively slow speed of the justice system and the mainstream press around the world, we probably will not hear about whether people are managing to incidentally break through these guard rails to self harm right now, but there are no shortage of stories still being reported right now where people were still doing just that, such as in this story where the effect of the much vaunted “guard rails” in 2025 was that if you wanted it to write you a suicide note, it would refuse twice but acquiesce on the third try. I don’t see any reason to believe this fundamental issue has been addressed in the meanwhile, since it had been happening for years at that point. ↩
In this tutorial we can also see an incredibly rosy scenario presented, where a long-running workflow effortlessly compresses all of the necessary information into the new context, even if it uses a lower-fidelity model to do so, rather than the tangled and gnarly problem of problems which really are too big to fit in the context, which is to say, “most real-world problems”. This presents the context limit instead as a minor speedbump to be worked around rather than the fundamental flaw in LLM tooling. ↩
A heavily fictionalized seaport. This is not how actual dockworkers work. This is a simplistic metaphor about incidental benefits of instrumental tasks, it is not supposed to delve deeply into the mechanics of maritime shipping. In particular I know that cranes are more reliable than this and this is not actually how you would respond to a crane malfunction anyway. Feel free to share fun facts about maritime shipping if that is your special interest but please do not @ me to correct this metaphor. ↩
To my knowledge, none of their publicly-traded employers have posted a measurable improvement to efficiency outside the margin of error. ↩
Or any similar methodology. I don’t need people to adopt the exact practice that I proposed there. ↩

Python Insider: The Python documentation is now available in German

Sat, 26 Sep 2026 00:00:00 +0000

You can now read the Python documentation online in German!

Rodrigo Girão Serrão: TIL #146 – Using maturin through uv

Fri, 25 Sep 2026 08:34:00 +0000

Today I learned how to setup a Rust project that can be called from Python with PyO3 and maturin through uv.

When you follow the PyO3 getting started guide to create a simple Rust project that can be called from Python, the instructions you get assume you'll use a global Python installation to create a virtual environment and to install maturin into it. You can use uv through maturin, but if your project also has a Rust binary, things may break.

When you run a command like cargo run, cargo will see the dependency on PyO3 and it will then look for a Python installation. If you have no global Python installations — because you do everything through uv — or if your global installations aren't setup exactly like a vanilla, default installation, PyO3 might fail.

The fix is simple. In .cargo/config.toml add the environment variable PYO3_PYTHON that points to the Python inside your virtual environment:

# .cargo/config.toml
[env]
PYO3_PYTHON = { value = ".venv/bin/python", relative = true }

How to set up a Rust + Python project with PyO3 and maturin through uv

Here are all the steps to set up a Rust project that can be compiled into a binary executable and that can also be used from within Python:

% cargo new calculator
% cd calculator

Create the file lib.rs:

// lib.rs
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[pyo3::pymodule]
mod calculator {
    use pyo3::prelude::*;

    #[pyfunction]
    fn add(a: i32, b: i32) -> PyResult<i32> {
        Ok(crate::add(a, b))
    }
}

And update the file main.rs to depend on your calculator:

use calculator::add;

fn main() {
    println!("{}", add(1, 2));
}

If you run cargo run, you should get the result 3:

% cargo run
3

Add the PyO3 dependency from the Rust side:

% cargo add pyo3 -F abi3-py38

Update Cargo.toml to configure your crate type so it can be compiled for the Rust binary and for the Python bridge:

# Cargo.toml
# ...

[lib]
name = "calculator"
crate-type = ["cdylib", "rlib"]

Now, create a minimal pyproject.toml:

# pyproject.toml

[project]
name = "calculator"
version = "0.1.0"

[build-system]
requires = ["maturin>=1.0,<2.0"]
build-backend = "maturin"

Add the dependency on maturin and run it:

% uv add maturin
% uv run maturin develop
# ...
✏️ Setting installed package as editable
🛠 Installed calculator-0.1.0

Run Python with uv run python and test your package:

>>> from calculator import add
>>> add(3, 4)
7

At this point you're happy that you can use your Rust code from Python and may not realise that cargo run may no longer work, complaining about Python frameworks, not finding whatever it needs to link, or other weird errors.

Configure cargo to use the Python installation from the virtual environment by adding the file .cargo/config.toml:

# .cargo/config.toml
[env]
PYO3_PYTHON = { value = ".venv/bin/python", relative = true }

Try running cargo run again and note that everything still works:

% cargo run
3

Fixing issues with PyO3 +

...

LernerPython blog, from Reuven Lerner: Pandas dropna: The best way to remove NaN values from a series

Fri, 25 Sep 2026 06:00:00 +0000

Coming to Python Pandas from NumPy? You’ll reach for np.isnan:

s = Series([10, np.nan, 30])
s.loc[ ~np.isnan(s) ] # returns 10, 30

Unfortunately, this works. Better, use s.isna (or s.isnull).

But the best way to drop NaN? Use dropna:

s.dropna()  # returns 10, 30

The post Pandas dropna: The best way to remove NaN values from a series appeared first on LernerPython.

Glyph Lefkowitz: Who Is Open Source About?

Fri, 25 Sep 2026 00:50:00 +0000

Open source is, at least in part, about you, where “you” refers to the user.

Open Source Is Not About “Open Source Is Not About You”

In other words: Rich Hickey was wrong when he wrote “Open Source Is Not About You” and I’m tired of pretending otherwise.

Of course he’s not completely wrong, or his famous post would not have resonated quite so much in the first place. Obnoxious users who demand their personal use-cases be immediately addressed by volunteer maintainers for free should indeed be viewed as the pariahs that they are. Similarly, corporate users who want free support from the community that supplies their infrastructure to lower their costs. As should those who profit from this type of externalization by their own customers.

But the exchange of “open source” (or even “free software”) is not as simple as “I have prepared some software for you, please enjoy it, you have no right to complain”, and maintainers ought to have a precise understanding of the costs and benefits — as well as the ethical implications — of that exchange.

Right now we barely even articulate that the exchange exists, let alone that it establishes a long-term, subtle, and implicit relationship between maintainer and user.

Let’s fix that.

A Brief Aside about Meta-Ethics

When we talk about “obligations” and “rights”, of “shoulds” and “musts”, we are constructing an ethical system. The purpose of such a system is to develop social expectations and social consequences. There is not much use in me telling you that you are transcendentally evil for failing to follow some arbitrary recommendation that I have. But I am implying that I believe there should be consequences for your behavior. I am also implying that there probably already are some consequences, and they’re just not written down anywhere yet.

Therefore, a post like this, where I say that we should view our social obligations in a certain way, that is the beginning of a broader social conversation. I think there should be some consequences, so I am gesturing towards that possibility. Exactly what consequences?

For now, I’m not sure. Let’s figure it out.

What Are We Doing When We Do An Open Source?

Hickey, and his many acolytes in the years since his fateful post, asserts that the process of “open source” goes like this:

Maintainer makes a thing, and makes it available to users as a gift.
1. Maintainer may “love working with the team”.
2. Maintainer may be “proud of the work we do”.
Users accept the gift, and extract utility from it.
1. (Users MUST be grateful for this.)
A tiny fraction of users reciprocally contribute to the thing.
1. (Maintainers may be grateful for this.)

He makes various oblique references to the specific activities of his company, which does things vaguely related to his projects for money¹. These activities are exclusively characterized as for “customers”, however, a subset of the aforementioned users so tiny (“fewer than 1%”) as to nearly be an entirely distinct group.

Breezing past this process in an essay about obnoxious users demanding things they are not entitled to, one might nod along, as this sounds mostly sensible. Giving gifts is nice. I too love working with good teams and taking pride in things.

Examined more closely, however, it starts to logically fall apart. If you have consulting clients and that’s where all of your money is coming from, why are you bothering (as he repeatedly insists) “doing [things] for the community”? What was the point of releasing this code in the first place? You could love working with your team and be proud of the work that you do in a lot of different contexts; why bother implicating this horde of entitled and obnoxious people, if that’s all you’re getting out of it? What’s in it for you?

If we’ve left out something as fundamental as “why is the maintainer doing this”, perhaps this story leaves out some other important bits as well.

Why Are You Doing This?

There are many possible motivations for releasing and maintaining open source software. They are often subtle, often overlapping, and rarely clearly stated. Maintainers are not a monolith and not everyone does it for similar reasons. But let’s review a few reasons that someone might want to contribute.

Reputation

One reason that you might want to release some open source software is advertising. The most common form of this is self-promotion; if you are a visible, prominent contributor to an open source project, it stands to reason that you will have an easier time finding work in the domain of that project.

If you operate a consultancy, as Rich Hickey did at the time of his famous rant, then this reputational currency translates into advertising for your services. It’s a practical demonstration of the skills of your team.

The trade in this benefit is most like the traditional “gift economy” that open source has been compared to. You give the code to your users, which has some value, but the users give you back some reputation, in the form of their attention, their esteem, and possibly even their money if they become customers or employers.

Influence

Infrastructure is the most popular type of open source for a good reason. Programmers working on a problem are often hemmed in by sclerotic architectural choices which prevent them from solving problems in the way that they’d prefer to solve them. Major infrastructural investments are difficult to justify in a planning process, as their benefits are hard to prove. Sometimes the benefits are highly personal; different engineers have different aesthetic preferences about what types of equally-valid solutions they’d prefer to work with.

If you can develop your preferred type of solution and release it as open source, then you can influence how everyone else solves this type of problem. As an individual, such a position of influence can allow you to have some transferable expertise between employers. You know how to use the tool you developed, so you can be very quick and effective with it, and you can shape it to your ongoing taste over time.

If you’re an employer, and you can get everyone else to use your open source thing², this can reduce both your hiring and training costs. Potential employees can read the code, see that it’s good, and want to work at a place that produces good code like that. They can also read the code and become familiar with it in advance of coming to work for you, which means that you have a ready supply of developers who already know how your internal systems work.

The trade in this benefit is more like “soft power” than a gift economy. You give the code to your users, which has some value, but the users give you back the ability to dictate their technological agenda. You gain both the ability to influence their initial direction, and, as part of ongoing maintenance, to dictate their behavior over time.

Improvement

As an engineer, you might want to improve your own skills. Writing something proprietary and commercial cuts against this in two ways.

First, you will want to build something that already exists within your skill set, so that it will attract commercial interest and actually be competitive. Within the context of a larger team, you will want to personally be able to be immediately effective for similar reasons. But you still need a way to learn new things.

Second, you will want to build something somewhat secretively, so that the value you are producing is captured rather than released to the community. This means that you will be cut off from external sources of expert feedback.

As an organization, you might want to build the skills of your staff in similar ways.

The trade in this benefit is code for knowledge. You release the code or changes, and in return you expect your users to provide you good bug reports, and to induce at least some of them to become co-developers.

Outsourcing

As an engineer, you can only do so much on your own. Perhaps you want to have some influence over your infrastructure so you want to write it, but you also want to have a communal place to keep your infrastructure such that you can make a change to something to suit your needs, but you know that even if you walk away, someone else will maintain that change and keep it working across years or even decades of changes to underlying platforms, hardware, etc.

This sort of communal maintenance effort can be shared among all interested participants; if a thousand companies all need the same tool, if even a few dozen can share it, that reduces even their own load massively, let alone everyone else’s.

The trade in this benefit is more complex, since there’s less symmetry between the main maintainer and peripheral community members who also contribute code. The main maintainer is actually trading a namespace, a central place for people to contribute, coordinate, and release changes, rather than the code. They are a sort of market maker where then all the other contributors trade code for code within that market-ish structure.

In practice, this motivation produces a game theory problem where, when maintenance drops below a critical threshold, it creates a big enough crisis that at least some freeloading stakeholders will be forced to start making contributions.

Ultimately, however, this saves all involved parties a ton on maintenance, more eager volunteers who do not freeload in the first place get all the other benefits mentioned above as well.

A Brief Aside about your Chart of Accounts

Most companies account for open source maintenance work as simple overhead on ongoing projects. Sometimes it’s CapEx, sometimes it’s OpEx, but it’s just “whoever happens to be working on this thing to support whatever random product it’s a part of”.

This type of accounting creates distorting incentives, because it doesn’t recognize all the benefits above. Under such a fiscal regime, ongoing healthy maintenance becomes a ZIRP because when resources are more constrained, this apparent indulgence gets corrected.

The ancillary benefits that open source creates ought to be properly recognized. It shouldn’t just be buried as Wages or IT or whatever. If it’s helping you hire better engineers, some of that expense should be allocated to Recruitment Costs. If it’s materially improving your reputation among your customer base, some of it should go to Goodwill. If it’s getting your product in front of developers who are your customers, it should be in Marketing. Most importantly, if maintenance on an open source project is actually helping you maintain your enterprise-wide platform, it should not be squirreled away in some small team who happened to be the first one to adopt it.³

Exactly how these costs should be allocated and cross-charged to different departments depends heavily upon your organization and your specific chart of accounts. But “whatever, it’s just part of the software product” or “I guess it’s DevRel because the SDK is in there” is guaranteed to have your open source organization destroyed along with all those side-benefits the next time that there’s a cash crunch.

The Things that Aren’t Supposed To Be Benefits

These categories could be made as explicit, rational trade-offs, even if they are often implicit and subtle in practice. They are transactions where the maintainer gets something and the user gets something.

However, not everything that you are getting as a maintainer is something you are actually supposed to use to your own benefit. Being given trust in service of a responsibility is not a transaction.

“Oops, All Root Shells”

Open source code is code. In our modern world of absolutely pathetic sandboxing, installing code from somebody else gives them control over your system, even if it is somewhat indirect.

There is an unwritten rule that if I create an open source library, and you use it, it probably shouldn’t have a backdoor in it that gives me the credentials to your bank account. There is a trust relationship between the user and the maintainer, and here, we see the first obligation that the maintainer has. The maintainer is obligated not to use the user’s computer for their own gain.

This rule might seem obvious and straightforward. It might even seem unfair to you that I call the rule “unwritten”, because the rule is, in fact, written down in a few places: for example, in the npm Acceptable Content Policy, it says right there:

A few examples of unacceptable content:

…

Content containing malicious computer code, such as computer viruses, computer worms, rootkits, back doors, or spyware. This includes content submitted for research purposes. Tools designed and documented explicitly to assist in security research are acceptable, but exploits and malware that use the npm registry as a deployment or delivery vector are not.

I think we can all agree that a script which steals your bank credentials and sends them to me to buy a totally sick jet ski would qualify as “malware”, so clearly that is forbidden.

There is also an enormous gray area here. npm also explicitly allows “Information on how to pay, donate to, and otherwise support Package development”, but then goes on to explicitly forbid “Packages that display ads at runtime, on installation, or at other stages of the software development lifecycle, such as via npm scripts.”⁴ How are the lines drawn around these gray areas? “npm will continue to apply its judgment when deciding what content is acceptable.”

But also... this is forbidden by npm, not by the transcendental nature of “open source”. I could give away code that displays all kinds of ads to its users as a “gift” on my website. The exact structure of this policy is not uncommon, but it also isn’t exactly the same as other such sites. PyPI, for example, explicitly bans “cryptocurrency mining”, which NPM does not. Is cryptocurrency mining “not open source”? A lot of judgement calls are happening here about what is allowable in these “gifts” that you are giving to your users.

But I digress.

My point is that policy-making around this concept is not clear, there are lots of little disagreements around the edges, but there is a very strong consensus that while the user is giving you their trust here, that is not a trade. The deal is not “you give the user some code, the user gives you unlimited compute and access to all their financial accounts”. The user has made themselves vulnerable to your code on the strength of your reputation.

This creates an obligation for you to not do anything evil with that code, either intentionally or through negligence.

Security Updates Are Just Command And Control In A Funny Hat

All of this is just about the initial download of some code, and that is the way that Rich Hickey describes it, as if you just grabbed some code off a web page and put it in a folder that you like on your desktop. But that is not how open source relationships work today, if indeed it ever was.

The way it works today is that you add a dependency to your pyproject.toml or your package.json or your Cargo.toml and now your users are vulnerable not just to whatever you happened to upload in the first place, but to whoever happens to have your package index credentials.

This creates an obligation to maintain an operational security posture that protects your users from malicious updates.

The Roadmap Is Someone’s Life

Another kind of trust that the user is placing in you is the trust that you are going to have at least some kind of regard for their usage of your software.

In a perfect world, the user’s expectations could be clearly circumscribed. Whatever ongoing maintenance you commit to perform would be encapsulated in clear policies that you’d write up in advance, about exactly what kind of security response policy you have, how you will communicate when you no longer have the resources for maintenance, and so on.

But anyone who has been involved in any project at anything but the most extreme tier of operational maturity knows that 99% of the ecosystem relies on a set of loose conventions around how all that stuff works. We expect that maintainers will generally be around, that they’ll use existing tools like an issue tracker for triaging user bugs, GHSA and CVEs for security reporting, that they will mark the project as “archived” and maybe do a final release before abandoning it, that they will maintain a ChangeLog explaining at least a little bit of what is going on.

Users assume that those conventions will be followed when there are any gaps in explicit policy, or indeed if policy is lacking entirely. This assumption is reasonable, because otherwise nobody could ever use any open source without a stack of service contracts that nobody has any time to write.

The strongest such convention is that an actively maintained program will, at least, more or less keep doing what it does as time goes on. A user who has elected to use a bit of open source software has made themselves vulnerable to changes and breakages in that software by the mere fact of using it. In the time that they have used it and invested in it, they have not invested in:

creating alternative software to meet their needs,
maintaining data in formats that other software can read, or
learning how to use existing alternative software.

This can, and does, go badly wrong, when those expectations are mismatched.

How It Goes Wrong

Let’s say a maintainer creates an open source paint program, OpenPaint.

An artist, known for their unique style of making blended collages, switches from their previous app, ProprietaryPaint, to this new OpenPaint to make these culturally significant works of art. However, the maintainer decides that the ‘blend’ tool is kind of a pain to maintain, and they remove it in OpenPaint 2.

A few months later, the artist’s operating system vendor issues a security update that breaks OpenPaint, because older versions of OpenPaint were unknowingly abusing some platform API.

The maintainer releases a new OpenPaint 2.0.1 that addresses this incompatibility, but doesn’t care about version 1.x any more so they don’t bother to update that one.

This places the artist in an impossible situation. They can stay on an old version of their operating system, putting all their personal data at risk. Or they can upgrade to the new operating system, effectively either cutting off access to their livelihood, or forcing them to change their art style entirely.

Now, proprietary software can place users in similarly untenable positions (and in fact, it is more often proprietary software that does). But does the openness completely remove any obligation for this consideration? Should the OpenPaint team have to at least communicate the reasons for doing this, to give the artist some recourse?⁵

The only thing that “open source” does is that it allows the artist to pay a prohibitive amount of money to a new maintenance team to create a fork. This is rarely the kind of thing that individuals can manage.

This creates an obligation to at least consider how your users might be relying on you.

This is the most complex obligation of the bunch. Obviously it does not entitle every single user to infinite work from the maintainer, but it also shouldn’t entitle the user to nothing for having trusted these subtle implied claims that the maintainer is making by making their work public.

It is a nuanced and ongoing negotiation and I do not think we have a clear moral intuition about how it should work out. But we do need to figure out a way to work it out.

It also raises a clarifying question.

Why Are We Even Doing This, and Who Are We Doing It For?

People generally like to do things for more than one reason. We live in an economy where people need to make money, but we mostly prefer to make that money doing things that are useful, and that make other people happy.

So, yes, we create open source for self-interested reasons to improve our reputations, to improve our skills, to increase our influence and to share our maintenance burdens. In so doing we take on some level of obligation to not abuse the trust that is placed in us, even if that level of obligation is not clear.

But if we are not doing it to serve those users at least a little bit, then those motivations are going to quickly ring hollow. We will not increase our reputation with a person if we respond to their every request by telling them that we owe them nothing and that their opinions are worthless. We will not gain influence over a community if we ignore their desires.

Many interactions with open source maintainers are unnecessarily adversarial. This is of course partially the fault of those users, who should calibrate their expectations appropriately.

Still: maintainers could do a better job of listening before these interactions become toxic. There’s no reason that “open source users” should be an especially toxic group of people. At this point in history, that group is basically just … people with computers.

It’s like that old truism. If you meet one person who is a jerk to you, that’s their problem. But if everyone you meet, everywhere you go, is constantly abrasive to you and treats you like you’re doing something wrong, maybe it’s time to look inward.

If all open source users are entitled assholes, maybe it’s time to look for a structural problem.

Surprise, It’s About AI Again

Sigh.⁶

Users hate slop.

I know, dear AI-positive reader, your AI outputs are different from everyone else’s, you aren’t pushing thoughtless slop into your code, just because everyone else is and it is the inevitable terminus of using those tools. You aren’t “lazy vibe coding” with Claude, you’re doing “responsible agentic engineering”, which is different because you’re just built different.

Still, humor me, for a moment. Your users don’t know that. They know what it looks like when products that they like adopt slop. They know that they will start leaking data. Developers know that it will make them personally less secure. They know that they can expect more outages and that your code will inexorably decline in quality.

In other words, your users are going to assume that this means you are violating that final obligation that the software should keep working.

Your users are going to tell you to stop, and they are probably going to get mad. Maybe you, or a plurality of your team, also want to stop, maybe you disagree with them, but in any case you need some way to have that conversation in a way that does not immediately overflow into every adjacent discussion forum. Users need to feel welcome in some space so they can have the discussion in that space, and not explode out into a thousand different group chats and social media threads.

This post was inspired by yet another prominent open source community discourse where a ton of angry users showed up to yell at developers to stop accepting LLM-generated code. I’m not going to link to any of these, because we don’t need any more fuel for the discourse fire. But there is more than one such case and the pattern is becoming familiar.

On social media - usually BlueSky or Mastodon, but sometimes a user group forum - users become aware of some AI-adjacent policy. They show up in a horde to the developer forum or mailing list. They loudly start demanding the project take a hard stand⁷ against AI. This pressure is simultaneous, but uncoordinated; extremely repetitive, very diverse, often inconsistent, and pretty stressful, especially if you’re a burnt-out maintainer with other things to be doing who may not even like AI yourself in the first place.

Believe me, I get it. It can be very unpleasant to deal with.

Like most problems that AI is causing, though, it’s not really an “AI” problem as much as it is a pre-existing dumpster fire that “AI” is pouring gasoline onto. In this case, an online mob is the language of the unheard⁸.

If Users Are Mad It’s Probably Already Too Late (But Maybe You Can Get Ready For Next Time)

One day, all of a sudden, you’re getting feedback from a bunch of users that are using inappropriate channels to complain. But did they already have appropriate channels to use?

Did you have a place for people to congregate and discuss your project? To make orderly complaints in a way that will be legible to you? Or do you just have a GitHub Issues page, which non-technical users have no idea how to interact with, and a forum for developers, where users don’t know the norms and any arriving brigade of pissed-off users will be seen as disruptive and inappropriate?

I don’t want to be throwing any stones from within my particular glass house. Setting up such a place has gotten harder over the years. I don’t really have one, either.

Could I have one, though? IRC has been slowly dying, mailing lists are unpopular and present increasingly annoying moderation challenges, forum software is expensive to operate and keep maintained, Discord is a confusing mess and the upshot of all of this is every community needs community management and forum moderation. Which means that for my own small solo projects, I couldn’t possibly have such infrastructure because such infrastructure requires a dedicated second person to maintain it, and until someone volunteers for that, it’s not really feasible. Even for my larger projects you’d be surprised how slim of a skeleton crew we are getting by with, and we definitely don’t have a whole spare maintainer to go manage this, especially as we are under attack from the slopocalypse ourselves.

The nature of open source community is that most communities start too small to need such a thing, grow incrementally until one day they are suddenly way too big and needed one yesterday, and then suddenly they are too small again when interest wanes even a little bit. Even as we need it more and more, building and maintaining community infrastructure remains a challenge.

Even so, having a dedicated place for users — not maintainers — to converse amongst themselves, be an actual community, and present feedback to the developers, is fast becoming a necessary component of a successful community and not a nice-to-have.

In Conclusion

As trying as it can be sometimes, we maintainers all do get something out of open source, and it is good to be honest with your users — and with yourself — exactly what you want to get out of it. In order to know whether the juice is worth the squeeze, we must know both what the juice is, and what the squeeze is.

Part of the metaphorical squeeze is a set of obligations, and those are the most poorly defined of all. We should try to be clear about what those are too. Both about exactly what we believe we are signing up for, and also, about how we are willing to let our users hold us to account for them. Codes of conduct are a start here, but only the absolute barest bare minimum; “do not harass your colleagues or your users” is not a standard of excellence to aspire to, it’s just basic manners.

I can’t tell you exactly what your obligations are, only try to gesture at my idea of the outlines of the fuzzy moral intuition we’ve all been implicitly sharing up until now.

Drawing this line is not just for the benefit of the users, either. Maintainers already feel pressure, we already feel obligations. We resent that feeling of obligation. While there are a diverse array of reasons for that resentment, one big one is that it’s not clear, even to ourselves where the obligations end. Lashing out by saying “I promised nothing and I owe you nothing!” followed by some choice expletives feels cathartic, but it doesn’t really solve the problem, because we clearly don’t really believe that’s where the line is, or we would have already stopped there. We wouldn’t feel the need to say it.

It is going to be a very big collective endeavor to figure out exactly where that line is. The best time to have gotten started on that endeavor was 50 years ago.

But the second best time is today.

Acknowledgments

Somewhat to everyone’s surprise, I, too, do things for money, like writing this post. Please remember to like and subscribe ↩
Whether it was originally yours, or developed by an employee who happened to be on staff at the time, or adopted by an employee who just started contributing to it a lot, in any of these scenarios a company can benefit from increased consistency and increased familiarity. ↩
If the rule is that they must forever endure the searing budgetary pain of gripping the white-hot potato that they unwittingly caught when they first made a good technical choice, this creates a perverse long-term incentive. ↩
I also find it darkly amusing that there is an explicit affordance here made for advertising, specifically, “Packages with code that can be used to display ads are fine. Packages that themselves display ads are not.” This distinction rather gives the game away, that this is a website for carnies and not for marks, and that at some level we expect our users to deserve a lower level of respect than ourselves. But a full exploration of that is another blog post, or maybe a book, that I don’t have time to write right now. ↩
If you want the turbocharged ultra-dramatic version of this problem, make it open source drivers for an optical prosthesis that lets the users see instead of an art app. That level of immediate physical dependency could be clarifying. It does also start to edge into an area where you could say that biomedical devices ought to be regulated differently, and that’s not really a “software” problem but a “healthcare” problem and I’d mostly agree. Except for the fact that this is a very short distance away from breaking everyone’s screen-reader with no notice or recourse. ↩
Did you believe I could write a blog post in 2026 which wasn’t somehow about AI? I wish I could still believe that. ↩
It doesn’t help that many of the most pro-AI voices are starting to have an, ahem, discernible political valence that is very unpopular among users. ↩
My apologies to MLK. ↩
If you read this whole post you can see that I sure need the help with all that. ↩

Graham Dumpleton: A master class in decorators, patching and tracing

Fri, 25 Sep 2026 00:00:00 +0000

There is now a Workshops page on this site listing seventy free hands-on workshops, spread across five collections. They start with how decorators work in plain Python using nothing but the standard library, move on to what wrapt adds for decorators, monkey patching and object proxies, and finish with patching, testing and tracing real code using wrapture. Taken in order they amount to a master class on the subject, and you don't need anything installed to work through them.

Why I have been making these

My working life is in an odd place at the moment. I am on what has turned into an extended sabbatical, and I still haven't decided whether it ends with going back to a job or with retiring for good. The upside is that I have time to spare, and I have been putting it to use filling out the documentation and learning material for my open source projects, something that has always lagged well behind the code.

The other reason is that decorators, monkey patching and instrumentation are topics I have probably spent more time on than most people ever will. I have been maintaining wrapt for well over a decade, and it grew out of the monkey patching I wrote for the New Relic Python agent before that. A lot of what I learned along the way only exists in my head, or is scattered across old blog posts and issue discussions. Workshops are a way of getting that knowledge out in a form people can actually learn from, rather than it disappearing with me.

Starting with the standard library

The first collection is 14 Python decorator workshops. These replace the decorator workshops I announced back in April, which were hosted on Educates, with a rewritten and more focused set.

They use only the standard library. The first has you use decorators before writing one, putting a few from the standard library to work to find out what the @ line actually means. From there you write your first decorator, find out how a wrapper remembers the function it wraps, give decorators arguments, and see what functools.wraps does and doesn't fix. The middle of the collection deals with stacking decorators and with methods, which is where most decorators people write start to go wrong. That includes working out how obj.method() finds its instance by doing the binding by hand, since that is what explains why a class based decorator can't be used on a method without extra work. The last few are practical: decorating classes, caching results, registering functions the way Flask, Click and pytest do, retrying and handling errors, and decorating async functions.

Decorators, patching and proxies with wrapt

In the April post I said the natural follow on would be a course built around wrapt. That has now happened, as three collections in the wrapt workshops.

The first collection, of 12 workshops, covers writing decorators with wrapt. Each workshop puts the wrapt version beside the standard library version it replaces, so you can see what each one gives you. It starts with the wrapper function wrapt expects and what the instance argument tells you about whether you are decorating a function, an instance method, a class method, a static method or a class. Later workshops cover keeping state in a decorator, switching a decorator off, validating arguments, per instance caching of methods, synchronising calls across threads and in async code, and changing the signature a decorated function reports.

The second collection, of 10 workshops, is on monkey patching code you didn't write. It covers patching every kind of method, taking a patch out again, patches which only last for a block of code, why a patch applied correctly can still do nothing, applying a patch before the target module has even been imported, and patching instance attributes. It ends by putting all of that together into the shape every instrumentation agent ends up having.

The third collection, of 10 workshops, is on object proxies, where one object stands in for another. You start by writing a delegating class by hand and seeing what it gets wrong, then find out what a proxy passes through to the object it wraps and what it deliberately doesn't. From there it covers intercepting special methods, the function wrapper that sits under every wrapt decorator, lazy proxies used for deferring imports, holding a function weakly, and pickling and copying a proxy.

Patching, testing and tracing with wrapture

The final collection is the 24 wrapture workshops, which I first mentioned when wrapture reached its first beta. They build on everything before them and range quite widely.

For testing, they cover writing unit tests by wrapping the real code rather than replacing it, recording what the real code did and turning that into a test, behaviour that changes over time, async code and generators, using wrapture properly with pytest, and converting an existing test suite that uses unittest.mock. For tracing, they cover a program narrating its own calls, tracing a program without changing it, analysing a trace in a notebook, recording each request to a Flask application as a tree of calls, finding slow code, exporting to OpenTelemetry, and following one trace across two processes. They also return to monkey patching as a discipline, changing what a third party library does in a way you can reverse, and finish with writing an instrumentation package for a library nobody has covered yet.

You don't need to do them all

Although the collections form a path from start to finish, nobody needs to work through all of them. If you are fairly new to Python, the decorator workshops, plus the first few of the wrapt decorator workshops, are probably all you will want. The later wrapt workshops, and much of wrapture, go into territory most Python developers never need to visit.

Equally, you can just pick out whatever looks interesting, or whatever covers a problem you have right now. If you already know decorators and need to patch a library you don't control, start with the wrapt monkey patching workshops. If you want better tests, or need to understand what a running application is actually doing, go straight to wrapture. Within a collection the workshops are ordered so each builds on the one before, but you can jump in anywhere.

How the workshops are hosted

Each set of workshops lives in its own repository on GitHub. The workshops run in JupyterLab using jupyterlab-workshop, an extension I wrote which puts the workshop instructions in a side panel beside the notebooks, terminals and files you work with. I wrote about it in Introducing jupyterlab-workshop, and about how a workshop is put together in Writing a workshop for JupyterLab.

When you open a collection, the extension shows its workshops in the order to take them, what each covers, and how far you have got with each.

Opening a workshop puts its instructions in the side panel. Actions in the instructions do things in the session for you, such as creating a notebook or running a cell, and checks confirm you have done a step before you move on.

There are a few ways to launch a collection, and the page for each collection on this site has buttons for them. The decorator workshops can run entirely inside your browser using JupyterLite, where Python itself runs in WebAssembly. Nothing runs on a server, and your work is kept in your browser's storage between visits. That is what the second screenshot above shows. For now only the decorator workshops run this way.

Every collection can also be launched on mybinder.org, a free public service which needs no account. It builds the repository into a temporary JupyterLab session, which can take a minute or two, and the session is discarded when you finish. Alternatively, GitHub Codespaces runs the same setup under your own GitHub account, using your Codespaces allowance, and keeps the codespace around until you delete it. If you would rather use your own machine, the README in each repository explains how to run the workshops locally.

What comes next

These collections will keep being refined, and I would like to hear about anything which is confusing or wrong. The GitHub repository for each collection is the place to raise an issue.

Beyond these, I plan to do workshops on WSGI and mod_wsgi, which is the other area where I have years of accumulated knowledge that has never been written down properly. I also want to look at what workshops I could create for people newer to Python, alongside the more detailed ones I have been doing so far. If there is a topic you think is badly served by what is already out there, let me know.

PyCon: PyCon US 2026 Recap and Recordings

Thu, 24 Sep 2026 14:38:40 +0000

As we close the books on PyCon US 2026, we can’t express enough gratitude to everyone who joined us for our first year in Long Beach, CA, and made our 7 days together a special and unforgettable experience.

We had an amazing and diverse group of community members join us for PyCon US 2026, attending from 58 different countries! By the numbers, we welcomed a total attendance of 1,901 Pythonistas to the Long Beach Convention & Entertainment Center. We’re proud of the work we did with all who supported the Python ecosystem and helped make PyCon US 2026 a huge success.

Check out a full, comprehensive recap of this year’s PyCon US conference here:

Are you already missing PyCon US? Check out this highlight reel for key moments, insights, and all the PyCon US 2026 energy:

Find many more photos from PyCon US 2026 on our Flickr account.

For anyone who couldn’t join us or would like to rewatch any of this year’s fabulous content, all PyCon US 2026 recordings are available on the PyCon US YouTube channel! Be sure to subscribe to our channel for notifications of any new content.

We send a huge thank you to all the presenters and speakers for their time, energy, and efforts in providing the wonderful content presented at PyCon US 2026, as well as to our incredible AV team, Altitude C, for their hard work and attention to capturing recordings and providing AV this year.

The attendees, volunteers, speakers, staff, and sponsors truly make PyCon US what it is! The work of the Python Software Foundation is only possible with you all. A huge heartfelt thank you to the whole community.

Save the Date!

We can’t wait to see you all back in Long Beach, California, for PyCon US 2027! Be sure to mark your calendars - we’ll see you there May 12-May 18, 2027!

If you’d like to be notified when the CFP opens and when tickets go on sale, you can watch this blog or subscribe to PyCon US News. Until then, if you have any questions or feedback, please reach out to pycon-reg@python.org.

Django Weblog: DSF member of the month - Ken Whitesell

Thu, 24 Sep 2026 14:13:21 +0000

For September 2026, we welcome Ken Whitesell as our DSF member of the month! ⭐

Ken has long been part of the Django community, serving for many years as an helper in the Django forum and recipient of the Malcolm Tredinnick Memorial award. He has been a volunteer for DjangoCon US for over ten years. He is a DSF member since September 2017!

You can learn more about Ken by visiting Ken's blog and his GitHub Profile.

Let’s spend some time getting to know Ken better!

Can you tell us a little about yourself? (hobbies, education, etc)

Hi everyone! I've been retired for a little more than a year now. After 45 years working in software development, I'm now free to spend my time working on what interests me. (You could say that what used to be my hobby is now my profession.) I'm currently living in the mountains about 60 miles south-east of Pittsburgh.

I mostly consider myself a boardgamer. Boardgaming has been a serious hobby for me for more than 50 years now, and has been one of the driving forces in my personal development as a programmer. Not in terms of programming or developing games, but doing analysis. I enjoy looking at the probabilities and patterns that may exist in particular games. To a lesser extent, I'm starting to develop an interest in using AI to create computer opponents.

My education was primarily informal. I had a BASIC class in high school, along with a touch of Fortran and COBOL. College didn't go nearly as well - I withdrew about mid-way through my first semester. (I guess I would say that I really wasn't ready for it on a number of different levels.)

About nine months later, I enlisted in the US Air Force. That's where my education really took off. I had a variety of experiences that exposed me to technologies that I wouldn't have otherwise been able to see. The training opportunities were amazing, and I'd like to think I took advantage of most of them. Beyond that, the rest of my education has been primarily self-directed.

How did you start using Django?

I was first exposed to Django at the first PyCon after it was released, but my job and other interests prevented me from looking at it in detail. It wasn't until 2014 when I took a job to help build a system using it that I got serious about learning it.

What other framework do you know and if there is anything you would like to have in Django if you had magical powers?

Oh my. We could split a lot of hair trying to define "framework" and "know". To some degree of knowledge I've worked with Drupal, WordPress, Joomla, CherryPy, Nevow, Spring, meteor.js, LifeRay, ASP.NET, and Zope. (There may be others that I've worked with but don't remember right off-hand.)

Aside from my professional responsibilities, my pet project is something I've been trying to do for more than 20 years. I've looked at a large number of frameworks

Is there anything from those other frameworks I'd like to have? I've never honestly thought about it in those terms. Every other framework I've used has come up short in at least one area I consider critical - that's why I've looked at so many of them.

I won't say that Django is perfect, but it is a perfect fit for me, how I look at the web, what I want to do, and how I want to approach those solutions. It's the closest match to how I think. I encounter a lot less friction when trying to get stuff done with Django than I ever had in any other framework.

What projects are you working on now?

My primary project is my boardgame-playing engine. I've got a handful of games that I enjoy playing, but are ignored by the "mass market" sites such as Boardgame Arena and Tabletop Simulator. I'm doing browser-based ports of them to support competitive play of those games. I also have a couple websites I maintain for my boardgaming community.

Which Django libraries are your favorite (core or 3rd party)?

First and most important to me is Channels. My boardgame site wouldn't exist if I didn't have a "Django-friendly" way of using websockets. Related to that, but not a Django library, would be HTMX. It provides the browser-side of the websocket connection in a way that works for me.

Beyond that, I rely heavily upon Django Crispy Forms, Django Extensions, and Treebeard.

What are the top three things in Django that you like?

Top of the list is the basic fact that it's written in Python. Given the choice, I'll pick working in Python over any other language.

Next is the ORM. I don't mind working with SQL, but I appreciate the layer that builds objects from the results.

Last of the three would be forms, both their ability to render HTML and to validate input.

You have been helping community members in the Django forum for many years and for some time in Django Discord. Thank you so much for your help. What made you start helping people in the first place and keep doing it?

Community has always been important to me. When I went to my first DjangoCon in 2014, I knew I had a lot to learn. Fortunately, there were a number of Djangonauts willing to spend their time helping me get past a number of conceptual hurdles.

At DjangoCon 2018 and 2019, Carlton Gibson gave talks titled "Your web framework needs you!" They were more than inspiring, they were reminders to me that as a member of this community, I had a responsibility to help keep it going. (In my case, that meant doing more than just working the registration desk.) I started looking for ways that I might be able to contribute.

Also in 2019, Andrew Godwin announced that the Django Forum was launched. I had been reading the mailing lists, but I wasn't particularly thrilled with that as a medium for discussion. I was looking forward to the forum becoming an active venue. I wasn't active at first - I didn't have any specific questions needing to be asked and there weren't any questions posted where I felt confident enough to answer them.

We all know what 2020 brought. In my case, it brought a lot of free time I wouldn't have otherwise had. In Feburary, I saw a question I felt comfortable answering. Then in March, I saw a couple more. I did my best to answer them. Since I wasn't getting corrected or told that my comments were unwelcome, I kept going. (Even after working with Django for 5 years at that point, I still wasn't all that comfortable with my understanding of a number of concepts.) Then during that summer when all my other plans had gone out the window, it became a major part of my day. I also began to realize that I was actually contributing to the Django Community and it felt good! I knew that I would never be able to really contribute code. But I also thought if I spent my time answering questions, then the people working on the code wouldn't feel the need to do that, and so indirectly I was helping move things forward by reducing at least one roadblock from their path.

So that became my motivator. I doubt I'll ever submit a PR. But if I can do anything that helps the Fellows or the other significant developers move Django forward, I'm going to be quite happy with that.

My activity on Discord is rather limited. For quick questions or open ongoing discussions I guess it's ok. But it would be my last choice of a platform to try and help someone with a detailed technical question.

You are a Malcolm Tredinnick Memorial award recipient, could you tell us a bit more about this award and what does it mean to you?

As far as the award itself, I think the Django docs say it best:

The award will be ... awarded annually, to the person who best exemplifies the spirit of Malcolm’s work - someone who welcomes, supports and nurtures newcomers; freely gives feedback and assistance to others, and helps to grow the community.

What does it mean to me? I see it primarily as validation and inspiration. It's validation that I think I am generally successful with what I'm trying to do. And it's inspiration for me to keep doing it. It's that little voice in me that says "Yes, what you're doing is worthwhile. You are helping people."

As far as knowing him, no. I was not fortunate enough for that to be the case. Malcolm passed in 2013, before I started really using Django. However, it's almost certain that I "met" him at least once while working at the PyCon registration desk from 2005 - 2010. But about the only thing I would have said to him would have been "Hi! Welcome to PyCon! Your name please?"

You are recently part of the security team, how have you seen Django security evolve through time?

To be honest, I'm not sure I'd describe it as "evolving" as much as simply "growing". One of Django's strengths to me has always been its focus on creating a secure environment. As far as I can tell, the project has always worked toward the ideal of "Security by design". And, when vulnerabilities are exposed, they get fixed. So I don't see it so much as anything is changing - just that the amount of work is increasing.

This is a process that has become more difficult through the years as Django continues to grow. The Django project has always been fortunate in that there have been some really amazingly astute people working to keep Django secure in the face of ever-increasing threats created by bad actors and AI. I'm just hoping to be able to help maintain that effort.

You know and have used Django for long time, do you have any advice for new learners or any Django user/developer?

For new people, my pet catch-phrase is "Don't fight the framework". Learn how Django does things, and adapt your mindset to match it. Do things the Django way. Don't try to make Django look or act like whatever framework you've used before. Once you really understand what's going on, if you want to make changes, fine. But ensure you understand the implications of those changes before making them.

Also, never forget that Django is Python. Nothing will help you understand Django more than having a very strong foundational understanding of Python.

What do you think of the evolution of Django through the years?

I think the stability and consistency through the years has been absolutely amazing. I could probably pull out some of the code I wrote in 2014 for Django 1.4 and have it running today with almost no effort. Django has done a wonderful job of moving things forward without unnecessarily throwing things away from the past. This stability is one of the reasons why I appreciate Django as much as I do.

After so much time in the Django community, what makes you stay?

It's the community itself, primarily the DjangoCon community. (Yes, I know that the Django community is significantly larger than just those attending DjangoCon, but my interactions with the community primarily revolve around DjangoCon, the forum, and (now) Discord.)

People come and people go. I miss some people that came to DjangoCons 10+ years ago, but I'm meeting new people every year - and that feeling doesn't change. There's something special about us, where everyone is open to share thoughts and ideas, and being friendly and helpful when doing so.

I start looking forward to the next DjangoCon the day after the previous one ends. How do you envision the future of Django from your perspective?

Technically, mostly stable with some gradual improvements. I don't see the possibility of any change being introduced that would make me want to make major changes to what I have running today. If something were to fundamentally change within Django that would break my existing system, I'd probably stay on 6.1 until I couldn't run it any more.

Is there anything else you’d like to say?

Thank you for inviting me to share my story!

Thank you for doing the interview, Ken !

LernerPython blog, from Reuven Lerner: New on the LernerPython practice system: A visual debugger

Thu, 24 Sep 2026 08:42:54 +0000

I’m a big fan of exercises, which is why the LernerPython platform includes hundreds of them — all using my in-browser practice system, which handles Python, Pandas, and Git, along with an AI-based Socratic tutor based on my writing.

As of today, the practice system is even better: It includes a visual debugger, allowing you to set breakpoints and trace through your Python, viewing global and local variables. It works on all of my exercises, including those involving multiple files and modules.

Moreover, the AI tutor sees the debugger’s current output, allowing you to ask it questions about the current state of your program and what you’re seeing.

I’ve got many more plans for improving my practice system in the coming weeks and months, and for making LernerPython an ever-more-attractive place to sharpen your skills.

Try a few sample exercises, with no charge or obligation: https://practice.lernerpython.com/classroom/540d7ab1a1/

And of course, you can try LernerPython free for two weeks at https://LernerPython.com/join.

The post New on the LernerPython practice system: A visual debugger appeared first on LernerPython.

LernerPython blog, from Reuven Lerner: PyArrow dtypes in pandas: Nullable integers with pd.NA

Wed, 23 Sep 2026 06:00:00 +0000

PyArrow dtypes in Python Pandas are nullable (with pd.NA):

s = Series([10, pd.NA, 30], dtype='int64[pyarrow]')

s is:

0 10
1 <NA>
2 30
dtype: int64[pyarrow]

The dtype is int64, but allows nulls. (Use np.nan? It’s turned into pd.NA.)

The post PyArrow dtypes in pandas: Nullable integers with pd.NA appeared first on LernerPython.

Python GUIs: Dynamically Adding Rows of Widgets in PyQt6 — How to use QGridLayout to add multiple widgets per row at runtime

Wed, 23 Sep 2026 06:00:00 +0000

I have a GUI where I dynamically add a QLineEdit for each image a user selects. That part works. But now I want to extend it so that each image gets a row of three text boxes — one for the filename, one for the width, and one for the height. How do I dynamically add multiple widgets horizontally for each new entry?

Adding a single widget per action is straightforward enough, but when you need a whole row of widgets each time? That's where QGridLayout becomes your best friend.

In this tutorial, we'll walk through how to dynamically add rows of QLineEdit widgets using QGridLayout in PyQt6. Each time the user selects images, a new row appears with three text boxes: the filename, image width, and image height. We'll also look at how you can use a custom widget to group related fields together.

Why QGridLayout?

If you've been using QVBoxLayout to stack widgets vertically, you've probably noticed that it only gives you one column. To place multiple widgets side by side and keep adding new rows, you need a two-dimensional layout. QGridLayout lets you place widgets by specifying a row and column, which makes it perfect for building table-like arrangements dynamically.

python

layout.addWidget(some_widget, row, column)

Each time you add a new file, you increment the row number and place your three widgets at columns 0, 1, and 2.

Setting Up the Window

Let's start with a basic main window that has a button to open a file dialog and a grid layout ready to receive our dynamic rows.

python

import sys
import os

from PyQt6.QtWidgets import (
    QApplication, QMainWindow, QWidget, QPushButton,
    QGridLayout, QLineEdit, QFileDialog, QLabel,
    QVBoxLayout,
)


class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.setWindowTitle("Image Selector")

        # Central widget and outer layout
        central_widget = QWidget()
        self.setCentralWidget(central_widget)
        outer_layout = QVBoxLayout()
        central_widget.setLayout(outer_layout)

        # Button to open file dialog
        self.button_open = QPushButton("Open Images")
        self.button_open.clicked.connect(self.load_images)
        outer_layout.addWidget(self.button_open)

        # Header labels
        header_layout = QGridLayout()
        header_layout.addWidget(QLabel("Filename"), 0, 0)
        header_layout.addWidget(QLabel("Width"), 0, 1)
        header_layout.addWidget(QLabel("Height"), 0, 2)
        outer_layout.addLayout(header_layout)

        # Grid layout for dynamic rows
        self.grid_layout = QGridLayout()
        outer_layout.addLayout(self.grid_layout)

        # Stretch at the bottom to push everything up
        outer_layout.addStretch()

        # Track how many rows we've added
        self.current_row = 0

    def load_images(self):
        paths, _ = QFileDialog.getOpenFileNames(
            self, "Select Images", "", "Images (*.png *.jpg *.bmp);;All Files (*)"
        )

        for path in paths:
            filename = os.path.basename(path)
            width, height = self.get_image_size(path)
            self.add_image_row(filename, width, height)

    def get_image_size(self, path):
        # Placeholder — replace with your own logic
        return 0, 0

    def add_image_row(self, filename, width, height):
        line_edit_name = QLineEdit(filename)
        line_edit_width = QLineEdit(str(width))
        line_edit_height = QLineEdit(str(height))

        self.grid_layout.addWidget(line_edit_name, self.current_row, 0)
        self.grid_layout.addWidget(line_edit_width, self.current_row, 1)
        self.grid_layout.addWidget(line_edit_height, self.current_row, 2)

        self.current_row += 1


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

Run this and click "Open Images." Each file you select gets its own row with three editable text boxes. Click the button again to add more.

How It Works

The add_image_row method is where the dynamic creation happens. Each time it's called, it:

Creates three QLineEdit widgets — one for the filename, one for width, one for height.
Adds them to the grid layout at the current row, in columns 0, 1, and 2.
Increments self.current_row so the next call places widgets on the next row.

Because QGridLayout handles positioning for you, you don't need to manually manage spacing or alignment. The widgets line up in neat columns automatically.

Extracting Real Image Dimensions

The get_image_size method above is a placeholder. If you want to extract actual image dimensions, you can use QImageReader from PyQt6 itself:

python

from PyQt6.QtGui import QImageReader


def get_image_size(self, path):
    reader = QImageReader(path)
    size = reader.size()
    if size.isValid():
        return size.width(), size.height()
    return 0, 0

This reads only the image header, so it's fast even for large files.

Adding a Computed Column

Since the original question mentioned calculating the area from width and height, let's add a fourth column that shows the computed area. We can make this column read-only so users don't accidentally edit it.

python

def add_image_row(self, filename, width, height):
    line_edit_name = QLineEdit(filename)
    line_edit_width = QLineEdit(str(width))
    line_edit_height = QLineEdit(str(height))

    line_edit_area = QLineEdit(str(width * height))
    line_edit_area.setReadOnly(True)

    self.grid_layout.addWidget(line_edit_name, self.current_row, 0)
    self.grid_layout.addWidget(line_edit_width, self.current_row, 1)
    self.grid_layout.addWidget(line_edit_height, self.current_row, 2)
    self.grid_layout.addWidget(line_edit_area, self.current_row, 3)

    self.current_row += 1

You'd also want to add a matching "Area" header label in the __init__ method.

Encapsulating a Row as a Class

As your rows get more complex, it helps to group the widgets for each row into their own class. This keeps MainWindow clean and makes it easy to access or update individual rows later.

python

class ImageInfoRow:
    def __init__(self, filename, width, height, grid_layout, row):
        self.line_edit_name = QLineEdit(filename)
        self.line_edit_width = QLineEdit(str(width))
        self.line_edit_height = QLineEdit(str(height))

        self.line_edit_area = QLineEdit(str(width * height))
        self.line_edit_area.setReadOnly(True)

        grid_layout.addWidget(self.line_edit_name, row, 0)
        grid_layout.addWidget(self.line_edit_width, row, 1)
        grid_layout.addWidget(self.line_edit_height, row, 2)
        grid_layout.addWidget(self.line_edit_area, row, 3)

Then in your main window, creating a row becomes a single line:

python

row = ImageInfoRow(filename, width, height, self.grid_layout, self.current_row)
self.image_rows.append(row)
self.current_row += 1

Storing each ImageInfoRow in a list (self.image_rows) lets you access or modify any row later — for example, to read back edited values or to remove a row.

Alternative Approaches

QGridLayout is a great fit here, but there are other ways to achieve similar results:

QVBoxLayout with QHBoxLayout rows — Make each row a QWidget with its own QHBoxLayout containing three line edits, then add each row widget to a vertical layout. This gives you self-contained row widgets that are easy to add and remove.
QTableView with a model — If you're dealing with many images or want features like sorting and filtering, a QTableView backed by a QStandardItemModel (or a custom model) is a more scalable approach. See the PyQt6 QTableView tutorial for details.

For a handful of images, the grid layout approach is simple and works well. For dozens or hundreds, consider switching to a model/view approach.

Complete Working Example

Here's the full example with real image size extraction and a computed area column:

python

import sys
import os

from PyQt6.QtGui import QImageReader
from PyQt6.QtWidgets import (
    QApplication, QMainWindow, QWidget, QPushButton,
    QGridLayout, QLineEdit, QFileDialog, QLabel,
    QVBoxLayout,
)


class ImageInfoRow:
    """Holds a row of QLineEdits for one image."""

    def __init__(self, filename, width, height, grid_layout, row):
        self.line_edit_name = QLineEdit(filename)
        self.line_edit_width = QLineEdit(str(width))
        self.line_edit_height = QLineEdit(str(height))

        self.line_edit_area = QLineEdit(str(width * height))
        self.line_edit_area.setReadOnly(True)

        grid_layout.addWidget(self.line_edit_name, row, 0)
        grid_layout.addWidget(self.line_edit_width, row, 1)
        grid_layout.addWidget(self.line_edit_height, row, 2)
        grid_layout.addWidget(self.line_edit_area, row, 3)


class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.setWindowTitle("Image Selector")
        self.setMinimumWidth(600)

        # Central widget and outer layout
        central_widget = QWidget()
        self.setCentralWidget(central_widget)
        outer_layout = QVBoxLayout()
        central_widget.setLayout(outer_layout)

        # Button to open file dialog
        self.button_open = QPushButton("Open Images")
        self.button_open.clicked.connect(self.load_images)
        outer_layout.addWidget(self.button_open)

        # Header labels
        header_layout = QGridLayout()
        header_layout.addWidget(QLabel("Filename"), 0, 0)
        header_layout.addWidget(QLabel("Width"), 0, 1)
        header_layout.addWidget(QLabel("Height"), 0, 2)
        header_layout.addWidget(QLabel("Area"), 0, 3)
        outer_layout.addLayout(header_layout)

        # Grid layout for dynamic rows
        self.grid_layout = QGridLayout()
        outer_layout.addLayout(self.grid_layout)

        # Push rows to the top
        outer_layout.addStretch()

        # Track rows
        self.current_row = 0
        self.image_rows = []

    def load_images(self):
        paths, _ = QFileDialog.getOpenFileNames(
            self,
            "Select Images",
            "",
            "Images (*.png *.jpg *.bmp);;All Files (*)",
        )

        for path in paths:
            filename = os.path.basename(path)
            width, height = self.get_image_size(path)

            row = ImageInfoRow(
                filename, width, height,
                self.grid_layout, self.current_row,
            )
            self.image_rows.append(row)
            self.current_row += 1

    def get_image_size(self, path):
        reader = QImageReader(path)
        size = reader.size()
        if size.isValid():
            return size.width(), size.height()
        return 0, 0


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

Click "Open Images," select a few image files, and you'll see a row appear for each one with the filename, dimensions, and computed area. Click the button again to add more images — each new selection appends to the existing list.

From here you could add scroll support (wrap the grid in a QScrollArea), add a "Remove" button per row, or switch to a QTableView if your needs grow. The core pattern — tracking a row counter and placing widgets into a QGridLayout — stays the same regardless of how you extend it.

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

Python Bytes: #497 Faster than light profiling

Wed, 23 Sep 2026 03:45:07 +0000

Topics covered in this episode: <ul> <li><a href="https://docs.python.org/3.15/library/profiling.sampling.html?featured_on=pythonbytes">Tachyon: A sampling profiler ships in Python 3.15's stdlib</a></li> <li><a href="https://blog.cloudflare.com/python-workers-ga/?featured_on=pythonbytes">Python Workers are now generally available on Cloudflare</a></li> <li><a href="https://flet.dev/blog/flet-1-0?featured_on=pythonbytes">Flet 1.0 - build cross-platform apps in Python</a></li> <li><a href="https://github.com/ljchang/marimo-book?featured_on=pythonbytes">marimo-book: Build static books from marimo notebooks</a></li> <li>Extras</li> <li>Joke</li> </ul><a href='https://www.youtube.com/watch?v=__iKh7BNDgM' style='font-weight: bold;' data-umami-event="Livestream-Past" data-umami-event-episode="497">Watch on YouTube</a> Sponsored by Logfire from Pydantic: <a href="https://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a> 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://docs.python.org/3.15/library/profiling.sampling.html?featured_on=pythonbytes">Tachyon: A sampling profiler ships in Python 3.15's stdlib</a> <ul> <li>Python 3.15 adds the <code>profiling</code> package per PEP 799: <code>profiling.tracing</code> (where cProfile moved) and <code>profiling.sampling</code>, the new sampler called Tachyon</li> <li>py-spy and Austin exist but copy raw interpreter bytes with no API, so every CPython release risks breaking them; one in the stdlib is a contract to stop breaking profilers</li> <li>Defaults: 1 kHz, main thread, wall clock, and a <code>-live</code> top-like view for poking at a slow server</li> <li>Output is flexible: pstats, <code>-flamegraph</code>, <code>-diff-flamegraph</code> against a baseline, <code>-heatmap</code> on source lines, <code>-opcodes</code> for specialized bytecode, <code>-gecko</code> for Firefox Profiler with GIL and GC markers</li> <li>Profiling modes: wall, cpu, gil (which function is starving my other threads?), and exception, plus <code>-async-aware</code> to see the task graph instead of just <code>select()</code>, <code>-all-threads</code>, and <code>-subprocesses</code> forking a profiler per child</li> <li>Near-zero overhead for production; guidance is 10-30 second windows on representative load, and free-threaded builds divide the rate by thread count</li> <li>Attach to a running PID, same minor version only; ptrace permissions are the main friction. A 3.14 backport already exists on GitHub</li> <li>Caveat: it only sees Python frames, so 90% in <code>calculate()</code> hides NumPy underneath. For native stacks there's Cronon from HRT, 200k samples/sec over DWARF, not yet open source</li> </ul> Calvin #2: <a href="https://blog.cloudflare.com/python-workers-ga/?featured_on=pythonbytes">Python Workers are now generally available on Cloudflare</a> <ul> <li>Python Workers are out of beta - now GA, "first-class" language on Cloudflare's Developer Platform</li> <li>No more manual JS interop: bindings (queues, R2, D1, Durable Objects) now work natively in Python, e.g. self.env.QUEUE.send({...})</li> <li>Runs on Pyodide (WASM-compiled Python), with real TCP socket support for DB connectivity</li> <li>Frameworks supported: FastAPI, Django, Flask; AI libs like OpenAI SDK, LangChain, MCP</li> <li>Underlying platform work formalized as PEP 783 (PyEmscripten), after a year of discussion</li> <li>Bottom line: write real Python on Cloudflare's edge, no JS glue code required</li> </ul> Calvin #3: <a href="https://flet.dev/blog/flet-1-0?featured_on=pythonbytes">Flet 1.0 - build cross-platform apps in Python</a> <ul> <li>Flet hits 1.0 - build Flutter-backed apps from pure Python, no frontend experience needed</li> <li>One codebase targets six platforms: iOS, Android, Windows, macOS, Linux, web</li> <li>150+ built-in UI controls, plus support for custom controls / wrapping Flutter packages</li> <li>Mobile now supports real Python packages: NumPy, pandas, Pillow, cryptography</li> <li>Comes with pytest-based UI testing and an MCP integration for AI coding assistants</li> <li>Milestone lands 4+ years after its first PyPI release (Sept 2022) - signals "production ready," not experimental</li> </ul> Michael #4: <a href="https://github.com/ljchang/marimo-book?featured_on=pythonbytes">marimo-book: Build static books from marimo notebooks</a> marimo-book is a Jupyter-Book-style static site generator built specifically for marimo .py notebooks. It ships polished multi-page sites with Material for MkDocs theming, full-text search, dark mode, and code copy, plus a content-hashed incremental build cache that drops rebuilds from 100+ seconds to roughly 3 seconds on real books. Standout extras include anywidget rendering without a kernel, static reactivity for discrete sliders via pre-rendered lookup tables, an opt-in WASM/Pyodide mode per chapter, and per-chapter launch buttons. <ul> <li>If you've wanted to publish a marimo notebook as a real book or course site without hosting a kernel, marimo-book gives you the static, searchable, fast-loading output you'd expect from Jupyter Book.</li> <li>Alpha (0.1.x), but in production: pin marimo-book>=0.1.5,<0.2; the book.yml schema is stable for v0.1, and <a href="http://dartbrains.org/?featured_on=pythonbytes">dartbrains.org</a> is a real-world user.</li> <li>Two-stage build by design: a marimo-aware preprocessor emits plain Markdown + inline HTML, then mkdocs (Material today, zensical tomorrow) renders it. Not a mkdocs plugin, so the shell stays swappable.</li> <li>Interactive widgets without a kernel: anywidget Canvas/Three.js/Plotly mounts render statically, and mo.ui.slider with explicit steps gets pre-computed as a static lookup table.</li> <li>WASM escape hatch per chapter: set mode: wasm and the chapter routes through marimo's MarimoIslandGenerator, shipping the marimo runtime + Pyodide bundle for full reactivity where you need it.</li> <li>Per-chapter launch buttons and extras: readers can jump to molab, GitHub, or a downloaded .py; optional [social], [linkcheck], and [pdf] extras cover OG cards, htmlproofer, and WeasyPrint PDF export.</li> <li>Sandboxed notebooks: the sandbox mode reads PEP 723 inline metadata and provisions per-notebook envs via uv for portable builds, at the cost of slower first runs.</li> </ul> Extras Calvin: <ul> <li>Great overview of a new feature in Python 3.15 - <a href="https://realpython.com/python315-frozendict/?featured_on=pythonbytes">frozendict</a></li> </ul> Michael: <ul> <li><a href="https://krebsonsecurity.com/2026/09/microsoft-plugs-nearly-1000-security-holes/?featured_on=pythonbytes">Microsoft Plugs Nearly 1,000 Security Holes in Windows</a></li> <li><a href="https://pybay.org?featured_on=pythonbytes">I’ll be speaking at PyBay 2026</a></li> <li><a href="https://www.pycon-nl.org?featured_on=pythonbytes">PyCon NL on October 15 in Utrecht</a> <ul> <li>Heading to Europe in October? PyCon NL is October 15th in Utrecht. One day, three tracks, about 350 people. It's an hour by train from Schiphol. There's also a session just for community organizers from groups like PyLadies, PyData, and Django. And the location fits. The Netherlands is where Python itself was born.</li> </ul></li> </ul> Joke: <a href="https://www.youtube.com/watch?v=FG8sUgjBGXs">You have homework</a> (no really ;) ) Watch <a href="https://www.youtube.com/watch?v=FG8sUgjBGXs">Interview with Big Data engineer in 2026</a> by Kai Lentit

Python Insider: The Python documentation is now available in Persian

Wed, 23 Sep 2026 00:00:00 +0000

PyCoder’s Weekly: Issue #753: frozendict, pytest Plugins, re.prefixmatch(), and More (2026-09-22)

Tue, 22 Sep 2026 19:30:00 +0000

#753 – SEPTEMBER 22, 2026
View in Browser »

Python 3.15 Preview: `frozendict`

Preview Python 3.15’s frozendict: build immutable mappings you can hash, cache, and share across threads, and learn where the freeze stops.
REAL PYTHON

Quiz: Python 3.15 Preview: `frozendict`

REAL PYTHON

claude -p “migrate our CI config to RWX”

Python is powering AI. Your build platform should keep up. RWX is CI/CD rebuilt for the agentic dev cycle: content-based caching, graph-based task execution, and agent sandboxes that share config and cache with CI. Teams at Honeycomb, ClickFunnels, and Verkada have already switched. See Why Engineers Love RWX → rwx.com
RWX (READWRITEEXECUTE) sponsor

pytest Plugins That Actually Change How You Test in 2026

Seven pytest plugins beyond the built-ins that changed how Peyton tests: pytest-httpx for HTTP mocking, pytest-randomly for order-dependency detection, anyio’s built-in pytest plugin for backend-agnostic async tests, syrupy for snapshot testing, pytest-watch for continuous feedback, freezegun for deterministic time, pytest-cov for coverage enforcement.
PEYTON GREEN • Shared by Anonymous

Soft-Deprecating `re.match()`

To provide consistency with other languages, Python 3.15 is soft-deprecating re.match() and introducing re.prefixmatch() instead. This article explains why.
HUGO VAN KEMENADE

Articles & Tutorials

Serve the Change Password Well-Known URL

When a password manager detects that a user’s password has been leaked, it can prompt them to change it, but the password change URL varies by site. The answer to such discovery problems is .well-known/ URL namespace. This article talks about how to build it in Django.
ADAM JOHNSON

Getting Started With Rust as Python Devs

Talk Python discusses Rust for Pythonistas with guest Christopher Trudeau. Learn why Rust is a go-to language for Python tools and extensions and how you can get started writing Python modules with PyO3.
TALK PYTHON podcast

Make Public API Tests Repeatable in Python

Network-dependent API tests can be slow and flaky. This article shows how VCR.py records real HTTP interactions once and replays them for fast, repeatable, offline tests. Use cases include GitHub API client and pytest, CI-safe testing, and live API tests.
CODECUT.AI • Shared by Khuyen Tran

Primer on Jinja Templating

With Jinja, you can build rich templates that power the front end of your web applications. But you can use Jinja without a web framework running in the background. Anytime you want to create text files with programmatic content, Jinja can help you out.
REAL PYTHON

Announcing the PSF Strategic Plan 2026

In May, the Python Software Foundation (PSF) shared the high-level goals of their Strategic Plan. It was sent out for community feedback and now has been adopted. It is a five-year plan covering 2026 to 2031.
PYTHON SOFTWARE FOUNDATION

`UnboundLocalError`: It’s Scope Decided in Advance

The variable has a value elsewhere in your program, just not in the scope Python already decided this line belongs to. Here’s how Python actually assigns scope, and why the fix usually isn’t global.
SYSTEM CRAFT PRESS • Shared by Bob Morrison

Functionally Zen

Practical tenets for Python simplicity: why pure functions, immutable data, and composition reduce complexity, cut mocking overhead, and keep side effects contained.
KYLE ADAMS

How to Review AI-Generated Python Code Efficiently

Learn an efficient workflow to review AI-generated code in Python: run ruff, mypy, bandit, and pytest, then catch the bugs agents get wrong.
REAL PYTHON

Agentic Engineering in Python: From Vibes to Evidence

Move from vibe coding to agentic engineering in Python, using tests, types, and code review to prove an AI agent’s changes are safe to keep.
REAL PYTHON

Automating EDA With `fg-data-profiling`

Automate exploratory data analysis by transforming DataFrames into interactive reports with one command from fg-data-profiling.
REAL PYTHON course

5 Design Patterns Used in My New Habit Tracker App

Bob has built a Django + HTMX based habit tracker. This article covers five small Python and design patterns used in his code.
BOB BELDERBOS

Projects & Code

fastapi-security-headers: OWASP Security Headers for FastAPI

GITHUB.COM/ALEJANDROTG-CODE • Shared by Alejandro Tacoronte González

citry: Frontend Web Framework for Python

GITHUB.COM/CITRY-DEV

tonio: A Multi-Threaded Async Runtime for Python

GITHUB.COM/GI0BARO

django-absurd: Django Integration for Postgres Absurd

GITHUB.COM/LINCOLNLOOP

securo: OSS Personal Finance Manager

GITHUB.COM/SECURO-FINANCE

Events

Weekly Real Python Office Hours Q&A (Virtual)

September 23, 2026
REALPYTHON.COM

Django on the Med 2026

September 23 to September 26, 2026
DJANGOMED.EU

PythonCamp Rügen 2026

September 26 to September 28, 2026
BARCAMPS.EU

Python Sheffield

September 29, 2026
GOOGLE.COM

Python Southwest Florida (PySWFL)

September 30, 2026
MEETUP.COM

PyBay 2026

October 3 to October 4, 2026
PYBAY.ORG

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

Talk Python to Me: #564: EVE Online Departs for Python 3

Tue, 22 Sep 2026 18:24:30 +0000

Every ship in EVE Online eventually undocks and leaves the station. This time, it's the whole game. EVE has run on Python 2 since it launched in 2003, all 2.4 million lines of it, on a custom Stackless interpreter that stopped at 3.8 and was archived last year. Destination: Python 3.12. The route runs through 6,500 lines of division that decide who wins a fight, and 100 gigabytes of pickled Python objects that have to survive the jump intact. Kristinn Sigurbergsson was on this show ten years ago. He's back, with Jamie Bannister, who is flying the EVE Online migration right now, and Thomas Dähling, who took EVE Frontier through first. In EVE, a destroyed ship is gone for good. There are no do-overs, and the universe has to stay online the whole way. Episode sponsors <a href='https://talkpython.fm/sentry'>Sentry Error Monitoring, Code talkpython26</a> <a href='https://talkpython.fm/training'>Talk Python Courses</a> <h2 class="links-heading mb-4">Links from the show</h2> <div>Guests Jamie Bannister: <a href="https://www.linkedin.com/in/jamiebannister/?featured_on=talkpython" target="_blank" >linkedin.com</a> Thomas Dähling: <a href="https://www.linkedin.com/in/thomasdaehling/?featured_on=talkpython" target="_blank" >linkedin.com</a> Kristinn Sigurbergsson: <a href="https://www.linkedin.com/in/kristinn-sigurbergsson-3260b4137/?featured_on=talkpython" target="_blank" >linkedin.com</a> EVE Online: <a href="https://www.eveonline.com?featured_on=talkpython" target="_blank" >www.eveonline.com</a> EVE Frontier: <a href="https://evefrontier.com?featured_on=talkpython" target="_blank" >evefrontier.com</a> 2.4 million lines of Python: <a href="https://www.eveonline.com/news/view/the-move-to-python-3-begins?featured_on=talkpython" target="_blank" >www.eveonline.com</a> Example of graphics, ships walk-through: <a href="https://www.youtube.com/watch?v=e2X1MIR1KMs" target="_blank" >www.youtube.com</a> Stackless: <a href="https://www.stackless.com/?featured_on=talkpython" target="_blank" >www.stackless.com</a> futurize: <a href="https://python-future.org/futurize.html?featured_on=talkpython" target="_blank" >python-future.org</a> blue: <a href="https://github.com/carbonengine/blue?featured_on=talkpython" target="_blank" >github.com</a> Dev blog on the Frontier upgrade: <a href="https://evefrontier.com/en/news/moving-into-the-future-upgrading-to-python-3?featured_on=talkpython" target="_blank" >evefrontier.com</a> Upgrading CARBON to Python 3: <a href="https://www.youtube.com/watch?v=4uaEhx7LNAc" target="_blank" >www.youtube.com</a> carbon-scheduler: <a href="https://github.com/carbonengine/scheduler?featured_on=talkpython" target="_blank" >github.com</a> Scheduling in Carbon: Leaving Stackless Python Behind: <a href="https://www.youtube.com/watch?v=-x299qHLQs0" target="_blank" >www.youtube.com</a> All of Carbon is on GitHub now: <a href="https://github.com/carbonengine?featured_on=talkpython" target="_blank" >github.com</a> did a whole course: <a href="https://training.talkpython.fm/courses/python-concurrency-deep-dive" target="_blank" >training.talkpython.fm</a> Trade Wars BBS (Wikipedia): <a href="https://en.wikipedia.org/wiki/Trade_Wars?featured_on=talkpython" target="_blank" >en.wikipedia.org</a> TW 3002 - TradeWars 2002, reimagined as a modern browser game: <a href="https://www.reddit.com/r/bbs/comments/1tyygnq/tw_3002_tradewars_2002_reimagined_as_a_modern/?featured_on=talkpython" target="_blank" >www.reddit.com</a> Watch this episode on YouTube: <a href="https://www.youtube.com/watch?v=ybboBZlQoAM" target="_blank" >youtube.com</a> Episode #564 deep-dive: <a href="https://talkpython.fm/episodes/show/564/eve-online-departs-for-python-3#takeaways-anchor" target="_blank" >talkpython.fm/564</a> Episode transcripts: <a href="https://talkpython.fm/episodes/transcript/564/eve-online-departs-for-python-3" target="_blank" >talkpython.fm</a> Theme Song: Developer Rap 🥁 Served in a Flask 🎸: <a href="https://talkpython.fm/flasksong" target="_blank" >talkpython.fm/flasksong</a> ---== Don't be a stranger ==--- YouTube: <a href="https://talkpython.fm/youtube" target="_blank" > youtube.com/@talkpython</a> Bluesky: <a href="https://bsky.app/profile/talkpython.fm" target="_blank" >@talkpython.fm</a> Mastodon: <a href="https://fosstodon.org/web/@talkpython" target="_blank" > @talkpython@fosstodon.org</a> X.com: <a href="https://x.com/talkpython" target="_blank" > @talkpython</a> Michael on Bluesky: <a href="https://bsky.app/profile/mkennedy.codes?featured_on=talkpython" target="_blank" >@mkennedy.codes</a> Michael on Mastodon: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" > @mkennedy@fosstodon.org</a> Michael on X.com: <a href="https://x.com/mkennedy?featured_on=talkpython" target="_blank" > @mkennedy</a> </div>

Django Weblog: New Technical Governance Approved

Tue, 22 Sep 2026 11:00:00 +0000

Both the Steering Council and DSF Board have approved DEP 19, which implements our new technical governance. Thank you to everyone who read the document and participated in the process! This was the effort of two different DSF boards and dozens of community members.

These changes were a revisitation of Django’s technical governance in which a simplification and reduction was made to make it more approachable to more people.

The most exciting change (in my opinion), is the new Steering Council Eligibility criteria. We defined a set of wide range qualities that members of the Steering Council could possess that would be advantageous. The hope is that this helps community members realize they are qualified to be a Steering Council member and stand for election.

The next steps are to update the documentation in the Django and djangoproject.com repositories with any necessary updates. After that the DEP will move to the final state and folder.

LernerPython blog, from Reuven Lerner: Pandas nullable integers: Keeping ints with Int64 and pd.NA

Tue, 22 Sep 2026 06:00:00 +0000

You have a Python Pandas series with ints + NaN. You don’t want float forced on you.

Solution: Use the “extension” type Int64 (note Initial Caps) and pd.NA:

s = Series([10, pd.NA, 30], dtype='Int64')  # must name explicitly

s is:

0 10
1 <NA>
2 30
dtype: Int64

The post Pandas nullable integers: Keeping ints with Int64 and pd.NA appeared first on LernerPython.

Andre Roberge: Breaking a four year hiatus to talk about the export keyword (PEPs 842 and 843)

Mon, 21 Sep 2026 17:24:52 +0000

I started writing this blog in 2004 and, every year I published at least one post until 2022. So four years of not writing about Python ... and, actually, four years of (essentially) not writing any code. It is time for me to start writing and coding again, this time about a proposed new Python keyword: export.

Sources of frustration

If you've ever written code and made it available for others to use, you might have encountered one or more of the following sources of frustration:

You change the names of some object intended for your private use only only to have users filing an issue, complaining that you broke their code.
You try to ensure that your public names are well-documented by adding them to __all__ but find that this forces you to duplicate the information at two different locations leading you sometimes to forget to keep __all__ up to date.
You read through the code of libraries you use but find it difficult to figure out which are meant to be public names and that you can safely use and which are meant to be purely private names since the required information is not immediately available where the objects are defined. Occasionally, you might see some names that begin with an underscore, which you know from convention that this is likely to indicate a private name ... but you cannot safely assume that names that do not begin with an underscore are meant to be public.
You decide to use some type-based linters and find that you suddenly have to write code differently, such as from module import NAME as NAME instead of the perfectly simple and valid Python syntax, from module import NAME, only so that the stupid tool will understand your intention.

There are other related sources of frustration, but this should suffice to give you the context. To address these and related issues, three related PEPs have been written:

PEP 842, since withdrawn, was written first, and suggested many changes, including creating a new list named __export__, somewhat related to __all__, and which could be used to enforce a clear separation between public and private names. With the initial version of PEP 842, attempting to import a private variable would have resulted in an ImportError. PEP 842 also included the introduction of export as a new "soft" keyword, useable in the following five cases:

Simple declaration: export NAME
Assignment: export NAME = VALUE
Declaring a function or class public: export def NAME() ... or export class NAME ...
A module re-export statement: from MODULE export NAME

PEP 843 also suggested the introduction of export as a soft keyword, but focusing on indicating that names imported into a module were meant to be public.

This means that the following three types of statements:

from module export A [, B, ...]

from module export A as B, ....

from module export *

would behave like their corresponding from ... import statements with the exception that all the names imported would be automatically added to __all__, thereby ensuring that __all__ would always be kept up to date without needing any duplicate entry from the programmer. Furthermore, a user reading the source code would immediately see which names were meant to be made public.

PEP 844: instead of introducing an new keyword, PEP 844 suggests the addition of two functions from the publicly available atpublic to Python's builtins. This library includes two decorators, @public and @private, that can be used to indicate how these names are intended to be used; in addition, @public automatically adds the name of the function or class to __all__. Simple assignments can be also declared to be "public" using a cleverly built function.

The introductions of these PEPs has lead to many long discussion threads on Python-discuss (PEP 842 - discuss, PEP 842 - revision, PEP 842 - postmortem, PEP 843 - discuss, PEP 844 - discuss, General discussion about what public means in Python, and perhaps other).

For now the discussion seems to have died down.

Source of inspiration

As I mentioned previously, I have done almost no programming in the past four years. I still read about Python, but didn't have the motivation to actually write code. That is, until I read these discussions and pondered if it would not be possible to simply "try out this new syntax". This lead me to go back to working on a fun project , and write two new import hooks, documented here and here.

With these, you can try out right now what it would be like to use the proposed export keyword cases suggested in PEP 842 as well as in a subset of those suggested in PEP 843.

Go try it out, and let me know what you think!

In the meantime, I plan to continue working on ideas, and resume working on friendly/friendly-traceback as well as on Reeborg's World, and implementing many of the suggestions made by users over the past four years.

LernerPython blog, from Reuven Lerner: Get Python help, one on one: my coaching sessions

Sun, 20 Sep 2026 10:37:56 +0000

Some of the most satisfying work I do happens one on one. You arrive with a real problem from your real job — code that will not behave, an architecture you are unsure about, a Git situation that has you stuck — and an hour later it is smaller, or gone.

I have offered these private coaching sessions for years, mostly to people who thought to ask. What I never did was describe them properly anywhere, which is a strange way to run something I enjoy this much.

So: I’ve now set up a page all about my coaching, at lernerpython.com/personal-coaching. Take a look — and if you need this kind of help, let’s talk!

What happens in an hour

Whatever you need. The session is yours, and people use it in very different ways:

You show me code you have written, and I tell you what I would change and why.
We plan a project before you write any of it, which is usually cheaper than planning it afterward.
We pair-program through a problem that has had you stuck for days.
You ask me the Git questions you have been quietly avoiding since 2019.
We work out where Claude Code actually fits into the way you already work.
You talk through a career decision, an interview, or what to learn next.

You do not need an agenda, or a tidy repository, or a well-formed question. “Here is my code, and here is what confuses me” has started plenty of excellent sessions.

Two things that make it work

It is private. Your code, your employer’s code, the architecture you are unsure about, the concept you feel you should have learned years ago: none of it goes anywhere. Ask me the question you would never ask in a public forum. That is rather the point of meeting one on one.

You get a recording. Nobody thinks clearly while taking notes. When we finish, I send you the video of the session, along with anything we built together — code, notes, a diagram, a Jupyter/Marimo notebook, a CLAUDE.md, or just a plan. It’s all yours to keep, and to use as you see fit.

What it costs, and what it does not require

A session is one hour on Zoom, for $300.

It has nothing to do with a LernerPython membership. You do not need to be a member, and booking a session does not sign you up for anything else. One hour, one payment, no obligation. If it helps and you want another in a month, book another; most people book once, get unstuck, and carry on.

Let’s talk!

Pick a time on my calendar, or read the details first on the coaching page.

If nothing on the calendar suits you, e-mail me at reuven@LernerPython.com and we will find a time that does. I am happy to get up early or stay up late for a session like this, wherever in the world you are. Ask, and we will work it out.

And if you are not sure whether your problem is a good fit for an hour, e-mail me and ask. I will tell you honestly, even when the answer is that you don’t need me.

The post Get Python help, one on one: my coaching sessions appeared first on LernerPython.

LernerPython blog, from Reuven Lerner: NaN in Pandas: Why you need np.nan, not pd.NaN

Sun, 20 Sep 2026 06:00:00 +0000

Missing data? NumPy calls it nan. Python Pandas displays it as NaN.

But: Pandas doesn’t define pd.nan or pd.NaN. NumPy removed np.NaN in version 2.0.

So you have to refer to np.nan from within Pandas, and it’ll be displayed as NaN.

The post NaN in Pandas: Why you need np.nan, not pd.NaN appeared first on LernerPython.