What is the practical benefit for this library?

[kopsha]

I do understand the motivation around using type annotations to reduce wiring friction and improve consistency. That said, in many cases explicit object construction (for example at the application boundary or in main()) seems to require roughly the same amount of code, while remaining more explicit and easier to reason about.
What kind of problems does python-injection solve that are difficult or impractical to address with straightforward, manual dependency wiring?

[remimd]

I think it depends on your relationship with dependency injection as a pattern. Personally, I use it extensively because it's a simple yet powerful pattern that enables great flexibility, so I tend to create many small classes to properly separate concerns.

As your application grows, you end up with more classes to instantiate and a deeper dependency tree. The problem is that when you want specific lifetimes per instance (singleton, scoped, transient) or need to swap implementations based on context, the code managing your instantiations can quickly become unwieldy.

In particular, scoped lifetimes and pull-based instantiation are extremely difficult to implement correctly without a framework.

[kopsha]

Thanks for the explanation, that clarifies the goals.

Much of what you describe around swapping implementations and managing deeper dependency trees maps, in my experience, to traditional Python techniques: environment-based wiring, runtime strategy selection, and conditional factories. These are usually handled explicitly via settings, factories, and simple conditionals at the application boundary. Containers centralize this logic, but don't uniquely enable it.

Where I do see a stronger case is scoped lifetimes, when instances need to be shared implicitly within a well-defined scope and created lazily. That’s genuinely harder to implement correctly without framework support.