Benjamin Müller’s Post

I used to scatter transformation logic all over my codebase. One base class fixed it. Frontend uses camelCase. Backend (Python) uses snake_case. And somewhere in between, someone's writing manual mappings It starts with one field. Then ten. Then it's everywhere, and nobody wants to touch it. Here's what I do instead: one base Pydantic class that handles it all automatically: Defining schemas in snake_case keeps your Python code Pythonic Auto-convert to camelCase on the output frontend gets what it expects Auto-map camelCase input back to incoming requests work One alias generator, inherited everywhere, no repeated logic The whole thing is ~8 lines of code. Every schema you write after that inherits and forgets about the problem. This isn't a big architectural decision. It's a small one. But it eliminates an entire category of confusion between frontend and backend teams permanently. Small decisions like this are what separate a clean codebase from a painful one. How does your team currently handle the camelCase vs snake_case gap convention, manual mapping, or something else entirely?

Stop writing try/finally blocks. Use context managers instead. I see this pattern everywhere in Python codebases: connection = get_db_connection() try: result = connection.execute(query) finally: connection.close() Nothing wrong with it — until you have 15 resources to manage across your project. Here's the cleaner version with contextlib: from contextlib import contextmanager @contextmanager def db_connection(): conn = get_db_connection() try: yield conn finally: conn.close() with db_connection() as conn: result = conn.execute(query) Why this is better: → Resource cleanup logic lives in ONE place → You can't forget to close — it's automatic → Stack multiple with a single `with` statement → Works with async too (`@asynccontextmanager`) My favorite use case: temporary environment changes in tests. @contextmanager def override_settings(**kwargs): old = {k: getattr(settings, k) for k in kwargs} for k, v in kwargs.items(): setattr(settings, k, v) try: yield finally: for k, v in old.items(): setattr(settings, k, v) Small abstraction. Massive reduction in bugs. What's your favorite Python pattern that most people underuse? 👇 #Python #Programming #BackendDevelopment #SoftwareEngineering #CleanCode

Astral is quietly doing to Python tooling what nobody else had the guts to do: rewrite everything in Rust and make the old tools feel embarrassing. Three tools. Same playbook. Absurd results. uv killed pip, poetry, pipx, and pyenv. One tool. Installs packages 10-100x faster. Manages Python versions too. If you're still using pip in 2026, I genuinely want to know why. And they ship a first-class Docker image too: docker run -it --rm astral/uv:bookworm-slim uv --version No manual installs. No version mismatches. Just works. Ruff replaced flake8, isort, and Black. Lints and formats your entire codebase in milliseconds. FastAPI, Airflow, and half the major Python projects adopted it within months of launch. It now has 100k+ GitHub stars. And now there's ty. A type checker to replace mypy and Pyright. Written in Rust. Still in beta but already: - 10-60x faster than mypy - 500x faster incremental updates than Pyright (4.7ms vs 2.38s on PyTorch) - Full language server with autocomplete, go-to-definition, auto-import One user checked a large codebase in 0.5 seconds. mypy took 18 seconds on the same codebase. The pattern Astral runs is simple: find a slow Python tool, rebuild it in Rust, ship compatibility, iterate fast on accuracy. They've done it three times now. It keeps working. For backend engineers writing Python services this isn't just a quality of life upgrade. Faster type checking in CI means shorter feedback loops. Faster linting means pre-commit hooks people actually leave enabled. That adds up. https://astral.sh #Python #SoftwareEngineering #BackendEngineering #DeveloperTools #Rust #OpenSource #PythonDev #Docker

Two days ago I wrote about how Astral was embarrassing legacy Python tooling with Rust rewrites. Today OpenAI announced they’re acquiring them. And it’s not just a talent grab. OpenAI is betting that the future of AI development runs on Python infrastructure that doesn’t waste developer time waiting for slow tooling. Think about it: if you’re building AI systems, you’re living in Python. You’re running type checks on massive codebases. You’re linting thousands of lines before every commit. You’re installing dependencies constantly. Astral made all of that 10-100x faster. Now OpenAI is acquiring the tooling that makes their core development workflow faster. But here’s what makes this interesting: Anthropic acquired Bun back in December. Two of the biggest AI labs. Two runtime/tooling acquisitions. Two completely different bets. OpenAI is betting on Python infrastructure. The language AI researchers already use. Make it faster, smoother, less painful. Anthropic bet on JavaScript/TypeScript infrastructure. The language the web runs on. The ecosystem where AI applications actually ship to users. OpenAI optimizes the research loop. Anthropic optimizes the deployment loop. Both make sense. Both signal something bigger: the tooling layer matters now. AI labs aren’t just building models anymore. They’re building the entire development stack around them. The compilers, the runtimes, the package managers, the type checkers. Whoever controls the tooling controls the developer experience. Whoever controls the developer experience shapes what gets built. This isn’t about Python vs JavaScript. It’s about two different theories of where AI development friction lives and how to eliminate it. We’ll see which bet pays off. Previous post on Astral: https://lnkd.in/gRys5FNW OpenAI announcement: https://lnkd.in/g-Sf3fSH Anthropic announcement: https://lnkd.in/gaEdxsTi #AI #Python #JavaScript #OpenAI #Anthropic #DeveloperTools #SoftwareEngineering #Rust #Bun #Astral

Two years into building backend systems with Python and FastAPI, one lesson keeps proving itself: Async isn't just a performance trick — it's a mindset shift. When I first started writing async endpoints, I treated it like a checkbox. "Use await, get speed." But the real value clicked when I saw how thoughtfully designed async flows could handle surges in traffic without the backend becoming the bottleneck. The difference between a system that holds up under pressure and one that doesn't often isn't the framework — it's whether the engineer truly understood why they made each architectural decision. That realization changed how I approach every API I build now. I ask: "What happens when 10x the requests hit this endpoint?" before I write a single line. It's made me a more intentional engineer, not just a faster one. For those building with FastAPI or any async framework — what's a lesson that changed how you think about backend design? Would love to hear what shifted your perspective. 👇 #BackendDevelopment #Python #FastAPI #SoftwareEngineering #APIDevelopment #LessonsLearned #TechCommunity

Pyright Guide: Installation, Configuration, and Use Cases Have you ever wanted faster type checking for Python without slowing down your workflow? Tools like MyPy can catch type errors, but they often feel slow or disconnected from the editor experience. This is where Pyright comes in. Pyright is a standards-based static type checker for Python designed for speed and fast feedback. It runs both as a command-line tool and as a language server, enabling real-time diagnostics while you write code....

🚀 Over the last few months, one project completely changed how I think about Python backend engineering. What started as a growing Python codebase slowly became something much bigger: a real-time, multi-process platform with independent long-running services, shared state, a live operator console, and plenty of messy runtime edge cases. The biggest learning for me was this 👇 Building systems is very different from just writing code. It’s not only about: ✅ “Does this logic work?” It’s also about: ⚠️ What happens when an API stalls? ⚠️ What happens when state goes stale? ⚠️ What should fail independently? ⚠️ How do multiple services still behave like one product? ⚠️ How do you keep the UI responsive while the backend is under pressure? Some of the most valuable lessons I learned while building this platform: 🔹 Split services by failure mode, not just by feature   🔹 Treat the database as a control plane, not just storage   🔹 Reuse live in-memory state before calling external APIs again   🔹 Add timeouts, deduplication, and cleanup paths early   🔹 Realize that many “UI bugs” are actually backend state-management bugs  This project pushed me to think less like: “Can I build this in Python?” and more like: “How do I make this recoverable, observable, and stable in production?” 🔧 I wrote a full breakdown of the architecture, tradeoffs, and engineering lessons here 👇 https://lnkd.in/ghBSNmMT Would love to hear how others think about multi-process design, shared-state systems, or backend fault tolerance in Python. #Python #SystemDesign #SoftwareArchitecture #BackendDevelopment #Concurrency #DistributedSystems

IO Ninja and Python Can Jam Together. As you know, IO Ninja excels as a UI debugger for serial, network, USB, and all other forms of communication. It offers a slick, polished user interface, a beautiful and lightning-fast logging engine, a sophisticated hex packet editor with packet templates, regex-based data markup, and many other powerful features. Read more via Tibbo: https://lnkd.in/dxyzDyft

We’re migrating our Python stack to Go 🐍 ⇒ 🦫 Thursday, we kill the infra hosting the python code. At lunch, someone joked: “we should put a giant countdown in the office so we don’t miss the deadline.” A year ago, that would have stayed a joke. This time, I opened Claude. Prompted what I had in mind. 2 minutes later, I had an HTML page. Dropped it on an S3 bucket. By the time people came back from lunch, the countdown was live. No tests. No review. No standards. And that’s fine. This code is not meant to last. It will be deleted in a few days. But it did something more valuable than being “clean”. It created a moment. We tend to think AI is about productivity, cost savings, replacing engineers. Sometimes it’s just about lowering the barrier between an idea and reality to zero. Not everything needs to be production-grade. Some things just need to exist.

Pytest has become one of the most powerful and developer-friendly frameworks for testing in Python. Here are some key benefits that make it a preferred choice: 1. Simple and readable syntax Pytest allows you to write tests with plain Python functions. No need for complex class structures. 2. Automatic test discovery It automatically detects test files and functions based on naming conventions like test_*.py. 3. Powerful assertions No need to use special assertion methods. Simple assert statements provide detailed failure output. 4. Fixtures for reusable setup Fixtures help manage test setup and teardown efficiently, making your code cleaner and more maintainable. 5. Parameterization support You can run the same test with multiple inputs easily. 6. Rich plugin ecosystem Pytest supports many plugins for reporting, parallel execution, and more. Example: import pytest #Function to test def add(a, b): return a + b #Basic test def test_add(): assert add(2, 3) == 5 #Using fixture @pytest.fixture def sample_data(): return 10, 20 def test_add_with_fixture(sample_data): a, b = sample_data assert add(a, b) == 30 #Parameterized test @pytest.mark.parametrize("a, b, result", [ (1, 2, 3), (5, 5, 10), (0, 0, 0) ]) def test_add_param(a, b, result): assert add(a, b) == result Pytest helps you write scalable, maintainable, and clean test cases, making it an essential tool for modern Python testing. #pytest #automationtesting #python #softwaretesting