I Designed a Python SDK That Relies on… Deep Inheritance?! | Issue #60


Hey everyone,

I love it when I come up with a design that uses exactly the things I thought were a sign of bad design.

In this week's video I show you how to build a clean Python SDK for a REST API. The idea was simple: create a reusable base model that handles all the CRUD operations so you can just write User.find() and user.save(), without duplicating logic all over your codebase.

Sounds great, right?

Well, after recording the video, I realized something: not all APIs will have all CRUD methods available. Maybe some endpoints only let you retrieve resources but not update them. Or maybe you can create records but not delete them.

So, how do you make that flexible?

Then I considered that you could use mixins to define per model exactly which methods each resource supports. Combine that with a singleton HTTP client and multiple layers of inheritance, and suddenly you have pretty much the exact design I usually tell developers to avoid. 😅

And yet in this specific context, it works surprisingly well.

If you want to see how it comes together (and decide for yourself whether I’ve finally lost my mind), watch the full video.

I’d love to hear your thoughts. Would you build your SDKs this way? Or do you have a different approach you prefer?

As always, happy coding!

Cheers,

Arjan


Do you enjoy my content on YouTube and would you like to dive in deeper?

🚀 Check out my online courses

My courses have helped thousands of developers take the next step in their careers. Check out these courses to help grow your skills and become a senior developer:

🔧 Need help with a complex codebase?

If your team is struggling with tech debt, unclear architecture, or cloud costs that keep creeping up, my team and I can help. We don’t just review, we get in and fix things. We’re only working with a few companies at a time to stay focused, so if it sounds like a fit:

Unsubscribe | Send by ArjanCodes

Wolvenplein 25, Utrecht, UT 3512 CK

The Friday Loop

Every Friday, you'll get a recap of the most important and exciting Python and coding news. The Friday Loop also keeps everyone posted on new ArjanCodes courses and any limited offers coming up.

Read more from The Friday Loop

Hey everyone, Python’s flexibility is great, but if you're working on a larger project it becomes hard to make sure not everything depends on everything else. There is a way to avoid that trap, and that's by using abstractions. Unfortunately, I often see production code with way too much coupling that can be easily improved by relying on abstractions. This week’s video shows simple abstractions using Callable, ABC, and Protocol. You’ll learn how to: Reduce unnecessary imports Decouple your...

Hey everyone, I was reviewing some of the projects I’ve worked on over the past year, and I noticed something interesting: I almost never use Python’s @dataclass anymore. Not because it’s bad. In fact, dataclasses are still a great feature of the language. But as my projects have grown more complex, especially with tools like FastAPI, Pydantic, and SQLAlchemy, I’ve found that dataclasses just… don’t fit the way I design software anymore. In my latest video, I dive into this in detail. You’ll...

Hi there, You’ve probably heard that serverless is the easiest way to deploy code to the cloud. And on the surface, it is. With Google Cloud Functions, you can literally deploy a simple Python function like this: def hello(request): return "Hello from Cloud!" A few lines of code. No servers. No infrastructure. But... there are quite a few limitations: No FastAPI or async support One route per function requirements.txt only, no pyproject.toml Cold starts for large dependencies No custom...