Maxim Sakhno

YouTube video by Видео с мероприятий {speach! Как в Python применяется инверсия зависимостей. Максим Сахно, Контур

My #PyCon RU 2025 talk (Best Speaker award! 🏆) is now on YouTube: youtu.be/MpQgrhLO6aE

English subtitles available! 🇬🇧

I break down the Dependency Inversion Principle, compare popular #Python #DI frameworks, and show why they matter for building better applications.

Our ints take like 28 bytes in memory. You really think we care about memory? 😂

Nim has a similar idea - combines compiled language speed with Python-like simplicity. I've had a really positive experience with it, but unfortunately it's still under the radar.

Fun fact: sum(0.1 for _ in range(10)) == 1 also returns False for the same reason. Math has left the chat 😄

It's IEEE 754 floats - the decimal 10.555 can't be exactly represented in binary (64-bit), so it's actually stored as ~10.55499999999999971578. Try print(f"{10.555:.20f}") and you'll see! Not a Python thing, all languages have this.

It's lazy evaluated too - if the first if is False, the rest won't even be checked

A low-resolution, close-up image of the 'Surprised Pikachu' meme. The yellow Pokémon is shown with wide eyes and an open mouth, capturing a classic expression of mock shock or disbelief.

Wait, this is actually allowed?! 🤯

If you interpret self.x += 1 literally: first we grab the class attribute, add 1 to it, then assign the result to the instance. So it should be A

In C/C++ you could manipulate this to return A (pointers, references, etc.), but Python's semantics make it clearly B

Same! Can't wait for t-string support to land in libraries and frameworks. More static analysis checks, less runtime surprises!

That said, for one-off disposable scripts? Yeah, type hints might be overkill

YES! A thousand times YES! 🙌 Type hints = saving everyone's sanity!

Depends on the task. Try sorting a 100GB log - Python crashes with MemoryError, but bash sort just handles it.

GitHub - maximsakhno/di-benchmarks: Performance benchmark comparing Litestar vs FastAPI dependency injection overhead. Performance benchmark comparing Litestar vs FastAPI dependency injection overhead. - maximsakhno/di-benchmarks

I have updated the benchmark with these new findings. You can find the full methodology, code, and results here: github.com/maximsakhno/...

Conclusion: Even when the application performs a significant amount of logic (event loop, HTTP parsing, routing, 4 DB queries), dependency injection overhead remains substantial.

A bar chart titled 'FastAPI' showing the relationship between Requests Per Second (RPS) and the number of dependencies (Num Deps). The chart displays three purple bars representing performance: 4439 RPS for 1 dependency, 4217 RPS for 2 dependencies, and 4083 RPS for 4 dependencies. The visual shows a steady, gradual decrease in throughput as more dependencies are added.

A bar chart titled 'LiteStar' illustrating the performance impact of increasing dependencies. The Y-axis measures Requests Per Second (RPS) and the X-axis shows the number of dependencies. The data points are: 4604 RPS for 1 dependency, 4085 RPS for 2 dependencies, and 3817 RPS for 4 dependencies. Red arrows indicate the percentage drop in performance: -11% from 1 to 2 dependencies, -7% from 2 to 4, and an overall -17% decrease from 1 to 4 dependencies.

Results: The trend persists, though the impact is lower due to the IO workload. FastAPI degrades linearly, while LiteStar drops 11% at 2 deps and 17% at 4 deps. The culprit is the TaskGroup overhead used for concurrent dependency resolution.

A technical diagram and code snippet comparing dependency injection structures in a Python web framework. The left side shows asynchronous code for three dependencies (dep11, dep21, dep22) and two GET handlers. 'handler1' is linked to 'dep11', which performs 4 database queries. 'handler2' is linked to two dependencies, 'dep21' and 'dep22', each performing 2 database queries. The right side features a flowchart visualizing these relationships, showing how one handler uses a single heavy dependency while the other splits the workload into two smaller ones, both totaling 4 DB queries.

Methodology: I tested endpoints with 1, 2, and 4 flat dependencies. To isolate the dependency resolution logic overhead, the total workload remains constant: 4 DB queries per request, distributed evenly among the dependencies.

In the previous thread, Litestar's RPS dropped 36% with 2+ flat dependencies due to TaskGroup overhead. 📉

How do #Litestar and #FastAPI perform with real DB queries in dependencies? Let's figure it out in this thread 🧵

#Python

A Python code snippet in an IDE demonstrating a type checking error. The function no_mutation is defined with an input parameter some_list typed as Sequence[int]. An attempt to call some_list.append() is highlighted with a red error from Pylance, stating: 'Cannot access attribute "append" for class "Sequence[int]".' This illustrates how using the Sequence type hint prevents accidental list mutation during static analysis.

You can use type annotations to prevent mutations explicitly. For example, use Sequence[X] instead of list[X]. Sequence is a protocol without mutation methods, so type checkers will catch attempts to modify it, even though Python won't stop you at runtime.

Hasn't worked once yet)

I’m looking for the catch, but it’s just 10.

Dataclasses and slots go hand in hand. Perfect for fixed schemas and high instance counts.

Yes, but uv

Looks impressive! Slimmer and more secure than the standard image. Does this mean we can safely swap the standard Python image for this minimal one in most production cases?

Summarized my findings and opened an issue. Hoping to help make #LiteStar just a little bit better.
github.com/litestar-org...

#Python #Backend #WebDev

Here’s the exact config I used for this benchmark:

🐍 Python 3.14
🚀 LiteStar 2.19 vs FastAPI 0.128
🛠️ Benchmark: wrk -c 128 -t 1 -d 1m

A "Swole Doge vs. Cheems" meme comparing LiteStar's performance scenarios. On the left, a large, muscular Doge is labeled "LiteStar's benchmark: Nested deps". On the right, a small, crying Cheems dog is labeled "The Reality: 2 flat deps".

That’s a wrap for now! 🧵

I have plenty of niche details and "deleted scenes" from this research that didn't fit into these posts. I’ll be sharing these extra insights over the next 2 weeks.

Follow along so you don’t miss the upcoming deep dives! 🐍🔍

Don't take my word for it — verify it yourself. 🛠️

I've published the full benchmark code on GitHub so you can run the tests and see the results on your own machine.

github.com/maximsakhno/...

A technical diagram showing the batching logic for a sequential dependency chain. On the left, a "Dependency Graph" shows a strict vertical hierarchy where Dep3 depends on Dep2, and Dep2 depends on Dep1. An arrow labeled "Kahn's Algorithm" points to the right, showing these nodes split into three individual batches: Batch 1 (Dep1), Batch 2 (Dep2), and Batch 3 (Dep3). Each batch contains only one node and is labeled "Await," indicating that the system will resolve them sequentially rather than using parallel TaskGroups.

Mystery solved! 🔍

In the official benchmark, the graph is just a linear chain. It results in stages with exactly one dependency each.

Since there’s nothing to parallelize, TaskGroups aren't even triggered!

Look at this linear "batching" below. 👇

A screenshot showing Python code and a flow diagram explaining asynchronous dependency injection. The code defines three asynchronous functions—async_dependency_one, two, and three—where each subsequent dependency injects the previous one. An API route handler async_dependencies_async then injects all three. Below the code, a diagram shows a "handler" box pointing down to "dep 1", "dep 2", and "dep 3", with horizontal arrows indicating that "dep 3" depends on "dep 2", which in turn depends on "dep 1".

So, what kind of dependency graph are they actually testing? 🧐

Let’s dig into the official benchmark source code.

Link: docs.litestar.dev/latest/bench...

Take a look at the setup below. What do you see? 👇