A README tells someone how to install your project. It doesn’t tell them how the project actually works. Here’s how to turn scattered markdown files into a real, browsable documentation site — using the same docs group you already defined back in pyproject.toml.
You already told your project which tools to use in pyproject.toml. Now let’s make sure those tools actually run — automatically, before every commit, without anyone having to remember.
Tired of ten scattered config files and a README full of pip install commands? Here’s how pyproject.toml became the single source of truth for modern Python projects — explained with restaurants, cars, and shopping carts instead of jargon.
The Abstract Factory pattern takes the Factory pattern one step further. Instead of creating one object, it creates a whole family of related objects that are guaranteed to work together. In this post we use a cross-platform notification system (mobile, web, and desktop) to show why a regular factory isn’t always enough, how Abstract Factory solves it, and how the two patterns compare side by side.
The Observer pattern lets objects subscribe to events and get notified automatically when something changes — no polling, no tight coupling. In this post we use a real-time stock price alert system to show why hardcoded notification logic breaks down, how to fix it with observers, how it compares to the Factory pattern, and where else you’ll run into this pattern in production Python code.
The Factory pattern lets your code create objects without hardcoding which class gets instantiated — making it easy to swap implementations without touching the rest of your app. In this post, we use a real-world notification system (email, SMS, push) to show the before/after, cover the function-based alternative, discuss how Factory and Singleton work together, and round out with other common uses in production Python code.
The Singleton pattern guarantees a class or function to only ever creates one instance, no matter how many times you call it. In this post, we break down why that matters for Python developers using SQLAlchemy, show you both a class-based and function-based implementation, and cover thread safety, the GIL, and where else singletons show up in real production code.
Testing a metaclass isn’t like testing a normal function — it fires when Python reads a class definition, not when you call it. This final post in the data-contracts series covers everything: autouse fixtures for global state isolation, testing metaclass behaviour by its observable outcomes, parametrize for every change type, and the heuristic edge cases that matter most.
Not all schema changes are equal. A new field is safe — consumers ignore it. A renamed field is breaking — consumers expecting the old name will fail silently. This post walks through how SchemaDiff classifies every change, how the rename heuristic works, and how the NotificationBus alerts only the teams that need to know.
When you inherit from ContractBase, three things happen automatically — registration, field extraction, and validation — before the next line of your code runs. This post explains exactly how: the MRO walk, why get_type_hints() beats __annotations__, closures, and the schema registry that ties it all together.