"I use IPython as my terminal's shell."

"IPython in the shell?"

"No, IPython is the shell."

"IPython? As the shell?"

"Only way to live."

Yesterday my exercise got downvoted, probably because its point was unclear. I'd like to try again with this reworked exercise. Hope you'll like this one better.

• Solution
• Explanation: “User-defined classes have __eq__() and __hash__() methods by default (inherited from the object class); with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).”

#Python #memory_graph #Equality #Hashing

An exercise to help build the right mental model for Python data.

• Solution
• Explanation: "User-defined classes have __eq__() and __hash__() methods by default (inherited from the object class); with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y)."

#Python #memory_graph #Equality #Hashing

So I recently inherited a legacy application that was a nightmare to maintain (tooling was clearly lacking and the codebase was pretty outdated). I quickly realized that if I ever wanted to actually enjoy working on it, I would have to give it a proper overhaul.

These are the 5 changes that had some of the biggest impact IMO:

1. uv: Being new to the Python ecosystem, I didn't want to figure out pip vs poetry vs pyenv vs virtualenv, so I just used uv and let it handle all of that. One Rust-based tool that installs and pins Python versions, manages the venv automatically and locks deps in a uv.lock for reproducible builds. Installs are also a lot faster, which makes CI a lot less painful.

2. Ruff:

Coming from JS, I really missed eslint --fix for automatically fixing linting issues and format code on save. Ruff brought that experience back. I know that there are plenty of linters and formatters in the Python ecosystem, but this one really stands out for me. Since it's built in Rust, it's super fast.

3. Dependabot:

Instead of remembering to update dependencies every few months, I enabled Dependabot. It automatically opens PRs when updates are available and then CI tells me whether they're safe to merge. It takes only a couple of minutes to set up but saves a lot of maintenance.

4. Pylance:

Without it, VS Code gives generic completions and never warns you about passing the wrong type until runtime. Pylance provides proper type-aware autocompletion, jump-to-definition (even in third-party libraries), inline documentation, and real-time type checking. I personally keep it on "basic" mode for legacy codebases, since "strict" surfaced hundreds of errors (thank you, but no thank you lol).

5. Pydantic:

Pydantic is basically Python's Zod: you declare a model, pass your data in and get either a validated typed object or a ValidationError naming the exact field at fault. It really helped me keep the codebase clean, with one place defining the shape of the data instead of raw dicts floating around. I use it wherever data comes from outside, like API payloads, forms, and env vars with pydantic-settings, which fails at startup instead of mid-request.

None of these tools changed the application itself. But together they made working on it a lot less frustrating.

I built idemkit after cleaning up duplicate charges one too many times.

The version everyone writes checks whether a key has been seen and replays the stored response. Two requests a millisecond apart both find nothing and both charge the card. And if the worker dies between charging and recording it, the retry charges again. Neither reproduces locally.

idemkit does it properly: an atomic claim instead of check-then-act, a lease that expires on the storage server's clock, and a fencing token so a stalled worker can't overwrite a good result.

from idemkit import idempotent, RedisBackend, MethodConfig 

@idempotent(
    backend=RedisBackend.from_url("redis://localhost:6379"), 
    config=MethodConfig(key_fields=["order_id"]), 
) 
async def charge(*, order_id, amount): 
    return await payments.charge(order_id, amount)

One core, three ways to use it: middleware for FastAPI/Flask/Django, a queue consumer wrapper or @idempotent on any function. Backends are Redis, Postgres, Mongo, DynamoDB, or in-memory for tests.

pip install idemkit, Apache-2.0: https://github.com/idemkit/idemkit

If you find it useful, I'd appreciate a star. It's new, so visibility helps a lot right now.

Recursion becomes much easier once students have the right mental model. Visualization will help get them there.

Take the Tower of Hanoi problem. The recursive solution is beautifully short, to move n disks we:

• first remove n-1 disks from the largest disk
• then move the largest disk
• and then move the n-1 disks back on top

But when students try to implement recursion, they often get stuck, and adding debug prints only adds to the confusion. That is where visualization can help to bring the right mental model. Here is the Tower of Hanoi problem solved recursively, visualized with 𝗶𝗻𝘃𝗼𝗰𝗮𝘁𝗶𝗼𝗻_𝘁𝗿𝗲𝗲: https://www.invocation-tree.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph_examples%2Frefs%2Fheads%2Fmain%2Ftowers_of_hanoi.py&timestep=0.5&play=

Instead of thinking about “a function calling itself again and again” students can now see the depth-first execution of a tree of subproblems showing the divide-and-conquer strategy in action. Once a student can think in terms of a tree of subproblems, recursion becomes much easier to understand, explain, and debug.

#Python #invocation_tree #Recursion

app.frontend() seems really handy!

So I have a Python package following the project structure outlined by the Python Packaging User Guide (Without the tests/ directory). Let's call it Package A.

This package can be used alongside another package, Package B, however no proper compatibility exists in Package A to support Package B's rendering system.

I want to make a compatibility package, Package AB, to make Package B's systems work with Package A. It shares the same dependencies as Package A, however it has Package B as a dependency.

How should I setup my project structure for Package AB? Should it be its own project directory? Should it be nested inside Package A's src directory?

Additionally, I have Sphinx /w Hatch setup with Package A for documentation. Depending on the setup chosen above, how should I setup documentation for Package AB?

Some things to note:

• Package AB would use classes and methods from Package A and Package B
• Package B's license (MIT) is compatible with Package A (GPLv3). Package AB would be licensed under the same as Package A

If more details are required, let me know.

The difference in Python OOP between:

• instance method
• class method
• static method

visually explained using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵: