rodi 2.0.6

Description:

rodi 2.0.6

Implementation of dependency injection for Python 3
Features:

types resolution by signature types annotations (type hints)
types resolution by class annotations (type hints)
types resolution by names and aliases (convention over configuration)
unintrusive: builds objects graph without the need to change the
source code of classes
minimum overhead to obtain services, once the objects graph is built
support for singletons, transient, and scoped services

This library is freely inspired by .NET Standard
Microsoft.Extensions.DependencyInjection implementation (ref. MSDN,
Dependency injection in ASP.NET
Core,
Using dependency injection in a .Net Core console
application).
The ContainerProtocol for v2 is inspired by punq.
Installation
pip install rodi

Efficient
rodi works by inspecting code once at runtime, to generate
functions that return instances of desired types - as long as the object graph
is not altered. Inspections are done either on constructors
(__init__) or class annotations. Validation steps, for
example to detect circular dependencies or missing services, are done when
building these functions, so additional validation is not needed when
activating services.
Flexible
rodi offers two code APIs:

one is kept as generic as possible, using a ContainerProtocol for scenarios
in which it is desirable being able to replace rodi with alternative
implementations of dependency injection for Python. The protocol only expects
a class being able to register and resolve types, and to tell if a type
is configured in it (__contains__). Even if other implementations of DI
don´t implement these three methods, it should be easy to use
composition to
wrap other libraries with a compatible class.
one is a more concrete implementation, for scenarios where it's not desirable
to consider alternative implementations of dependency injection.

For this reason, the examples report two ways to achieve certain things.
Examples
For examples, refer to the examples folder.
Recommended practices
All services should be configured once, when an application starts, and the
object graph should not be altered during normal program execution.
Example: if you build a web application, configure the object graph when
bootstrapping the application, avoid altering the Container configuration
while handling web requests.
Aim at keeping the Container and service graphs abstracted from the front-end
layer of your application, and avoid mixing runtime values with container
configuration. Example: if you build a web application, avoid if possible
relying on the HTTP Request object being a service registered in your container.
Service life style:

singleton - instantiated only once per service provider
transient - services are instantiated every time they are required
scoped - instantiated only once per root service resolution call
(e.g. once per web request)

Usage in BlackSheep
rodi is used in the BlackSheep
web framework to implement dependency injection for
request handlers.
Documentation
Under construction. 🚧