Welcome to Injector’s documentation!¶

GitHub (code repository, issues): https://github.com/alecthomas/injector

PyPI (installable, stable distributions): https://pypi.org/project/injector. You can install Injector using pip:

pip install injector

Injector works with CPython 3.6+ and PyPy 3 implementing Python 3.6+.

Introduction¶

While dependency injection is easy to do in Python due to its support for keyword arguments, the ease with which objects can be mocked and its dynamic natura, a framework for assisting in this process can remove a lot of boiler-plate from larger applications. That’s where Injector can help. It automatically and transitively provides dependencies for you. As an added benefit, Injector encourages nicely compartmentalised code through the use of modules.

If you’re not sure what dependency injection is or you’d like to learn more about it see:

The core values of Injector are:

Simplicity - while being inspired by Guice, Injector does not slavishly replicate its API. Providing a Pythonic API trumps faithfulness. Additionally some features are ommitted because supporting them would be cumbersome and introduce a little bit too much “magic” (member injection, method injection).

Connected to this, Injector tries to be as nonintrusive as possible. For example while you may declare a class’ constructor to expect some injectable parameters, the class’ constructor remains a standard constructor – you may instaniate the class just the same manually, if you want.
No global state – you can have as many Injector instances as you like, each with a different configuration and each with different objects in different scopes. Code like this won’t work for this very reason:
```
class MyClass:
    @inject
    def __init__(self, t: SomeType):
        # ...

MyClass()
```
This is simply because there’s no global Injector to use. You need to be explicit and use Injector.get, Injector.create_object or inject MyClass into the place that needs it.
Cooperation with static type checking infrastructure – the API provides as much static type safety as possible and only breaks it where there’s no other option. For example the Injector.get method is typed such that injector.get(SomeType) is statically declared to return an instance of SomeType, therefore making it possible for tools such as mypy to type-check correctly the code using it.

Quick start¶

See the project’s README for an example of Injector use.

Contents¶

Injector Change Log¶

0.20.1¶

Added support for PEP 604 union types (Python 3.10+), thanks to David Pärsson
Fixed building with pypandoc 1.8+, thanks to Søren Fuglede Jørgensen

0.20.0¶

Fixed handling of Union combined with Annotated, thanks to Tobias Nilsson
Fixed AssitedBuilder/child Injector interaction, thanks to Erik Cederberg
Made get_bindings() and injections work even if a injectee’s return type annotation is a forward reference that can’t be resolved

Backwards incompatible:

Dropped Python 3.6 support

0.19.0¶

Added the license to the source distribution, thanks to Joshua Adelman
Added Python 3.9 and 3.10 support, this includes fixing Python 3.10 compatibility, thanks to Torge Matthies
Improved the documentation, thanks to Takahiro Kojima
Improved the source distribution so that it can be used to build and install wheels, thanks to Janusz Skonieczny
Added requirements files for easier development, thanks to Greg Eremeev

Backwards incompatible:

Removed Python 3.5 support

0.18.4¶

Fixed a bug where only one of multiple NoInject annotations was interpreted

0.18.3¶

Fixed Python 3.5.3 compatibility

0.18.2¶

Added remaining type hints to the codebase so that the client code can have better static typing safety
Fixed UnsatisfiedRequirement string representation (this time for real)
Added forward return type reference support to provider methods

0.18.1¶

Fixed UnsatisfiedRequirement instantiation (trying to get its string representation would fail)
Fixed injecting a subclass of a generic type on Python versions older than 3.7.0
Fixed regression that caused BoundKey injection failure

0.18.0¶

Added new public get_bindings function to see what parameters will be injected into a function
Added new generic types using a draft implementation of PEP 593: Inject and NoInject. Those serve as additional ways to declare (non)injectable parameters while inject won’t go away any time soon noninjectable may be removed once NoInject is cofirmed to work.

Backwards incompatible:

Removed previously deprecated Key, BindingKey, SequenceKey and MappingKey pseudo-types

0.17.0¶

Added support for using typing.Dict and typing.List in multibindings. See multibind.
Added multibinding-specific provider variant: multiprovider
Deprecated using provider for multibindings
Fixed failure to provide a default value to a NewType-aliased type with auto_bind enabled
Deprecated Key, SequenceKey and MappingKey – use real types or type aliases instead
Deprecated using single-item lists and dictionaries for multibindings - use real types or type aliases instead

Technically backwards incompatible:

typing.List and typing.Dict specializations are now explicitly disallowed as bind interfaces and types returned by provider-decorated methods

0.16.2¶

(Re)added support for decorating classes themselves with @inject. This is the same as decorating their constructors. Among other things this gives us dataclasses integration.

0.16.1¶

Reuploaded to fix incorrectly formatted project description

0.16.0¶

Added support for overriding injectable parameters with positional arguments (previously only possible with keyword arguments)
Fixed crashes caused by typed self in method signatures
Improved typing coverage

Backwards incompatible:

Dropped Python 3.4 support
Removed previously deprecated constructs: with_injector, Injector.install_into, Binder.bind_scope
Dependencies are no longer injected into Module.configure and raw module functions (previously deprecated)

- Removed unofficial support for injecting into parent class constructors

0.15.0¶

Added type information for Injector.create_object() (patch #101 thanks to David Pärsson)
Made the code easier to understand (patch #105 thanks to Christian Clauss)
Opted the package into distributing type information and checking it (PEP 561)

0.14.1¶

Fixed regression that required all noninjectable parameters to be typed

0.14.0¶

Added NewType support
Added type hints

Backwards incompatible:

Passing invalid parameter names to @noninjectable() will now result in an error
Dropped Python 3.3 support

0.13.4¶

Deprecated with_injector. There’s no one migration path recommended, it depends on a particular case.
Deprecated install_into.

0.13.3¶

Fixed a bug with classes deriving from PyQt classes not being able to be instantiated manually (bug #75, patch #76 thanks to David Pärsson)

0.13.2¶

Fixed a bug with values shared between Injectors in a hierarchy (bugs #52 and #72)
Binding scopes explicitly (Binder.bind_scope) is no longer necessary and bind_scope is a no-op now.

0.13.1¶

Improved some error messages

0.13.0¶

Backwards incompatible:

Dropped Python 3.2 support
Dropped Injector use_annotations constructor parameter. Whenever @inject is used parameter annotations will be used automatically.
Dropped Python 2 support (this includes PyPy)
Removed @provides decorator, use @provider instead
Removed support for passing keyword arguments to @inject

0.12.0¶

Fixed binding inference in presence of * and ** arguments (previously Injector would generate extra arguments, now it just ignores them)
Improved error reporting
Fixed compatibility with newer typing versions (that includes the one bundled with Python 3.6)

Technically backwards incompatible:

Forward references as PEP 484 understands them are being resolved now when Python 3-style annotations are used. See https://www.python.org/dev/peps/pep-0484/#forward-references for details.

Optional parameters are treated as compulsory for the purpose of injection.

0.11.1¶

0.11.0 packages uploaded to PyPI are broken (can’t be installed), this is a fix-only release.

0.11.0¶

The following way to declare dependencies is introduced and recommended now:

class SomeClass:
    @inject
    def __init__(self, other: OtherClass):
        # ...

The following ways are still supported but are deprecated and will be removed in the future:

# Python 2-compatible style
class SomeClass
    @inject(other=OtherClass)
    def __init__(self, other):
        # ...

# Python 3 style without @inject-decoration but with use_annotations
class SomeClass:
    def __init__(self, other: OtherClass):
        # ...

injector = Injector(use_annotations=True)
# ...

The following way to declare Module provider methods is introduced and recommended now:

class MyModule(Module):
    @provider
    def provide_something(self, dependency: Dependency) -> Something:
        # ...

@provider implies @inject.

Previously it would look like this:

class MyModule(Module):
    @provides(Something)
    @inject
    def provide_something(self, dependency: Dependency):
        # ...

The provides() decorator will be removed in the future.

Added a noninjectable() decorator to mark parameters as not injectable (this serves as documentation and a way to avoid some runtime errors)

Backwards incompatible:

Removed support for decorating classes with @inject. Previously:

@inject(something=Something)
class Class:
    pass

Now:

class Class:
    @inject
    def __init__(self, something: Something):
        self.something = something

Removed support for injecting partially applied functions, previously:

@inject(something=Something)
def some_function(something):
    pass


class Class:
    @inject(function=some_function)
    def __init__(self, function):
        # ...

Now you need to move the function with injectable dependencies to a class.

Removed support for getting AssistedBuilder(callable=...)
Dropped Python 2.6 support

Changed the way AssistedBuilder and ProviderOf are used. Previously:

builder1 = injector.get(AssistedBuilder(Something))
# or: builder1 = injector.get(AssistedBuilder(interface=Something))
builder2 = injector.get(AssistedBuilder(cls=SomethingElse))
provider = injector.get(ProviderOf(SomeOtherThing))

Now:

builder1 = injector.get(AssistedBuilder[Something])
builder2 = injector.get(ClassAssistedBuilder[cls=SomethingElse])
provider = injector.get(ProviderOf[SomeOtherThing])

Removed support for injecting into non-constructor methods

0.10.1¶

Fixed a false positive bug in dependency cycle detection (AssistedBuilder can be used to break dependency cycles now)

0.10.0¶

injector.Provider.get() now requires an injector.Injector instance as its parameter
deprecated injecting arguments into modules (be it functions/callables, Module constructors or injector.Module.configure() methods)
removed extends decorator
few classes got useful __repr__ implementations
fixed injecting ProviderOf and AssistedBuilders when injector.Injector auto_bind is set to False (previously would result in UnsatisfiedRequirement error)
fixed crash occurring when Python 3-function annotation use is enabled and __init__ method has a return value annotation (“injector.UnknownProvider: couldn’t determine provider for None to None”), should also apply to free functions as well

0.9.1¶

Bug fix release.

0.9.0¶

Child Injector can rebind dependancies bound in parent Injector (that changes Provider semantics), thanks to Ilya Orlov
CallableProvider callables can be injected into, thanks to Ilya Strukov
One can request ProviderOf (Interface) and get a BoundProvider which can be used to get an implementation of Interface when needed

0.8.0¶

Binding annotations are removed. Use Key() to create unique types instead.

0.7.9¶

Fixed regression with injecting unbound key resulting in None instead of raising an exception

0.7.8¶

Exception is raised when Injector can’t install itself into a class instance due to __slots__ presence
Some of exception messages are now more detailed to make debugging easier when injection fails
You can inject functions now - Injector provides a wrapper that takes care of injecting dependencies into the original function

0.7.7¶

Made AssistedBuilder behave more explicitly: it can build either innstance of a concrete class (AssistedBuilder(cls=Class)) or it will follow Injector bindings (if exist) and construct instance of a class pointed by an interface (AssistedBuilder(interface=Interface)). AssistedBuilder(X) behaviour remains the same, it’s equivalent to AssistedBuilder(interface=X)

0.7.6¶

Auto-convert README.md to RST for PyPi.

0.7.5¶

Added a ChangeLog!
Added support for using Python3 annotations as binding types.

Terminology¶

At its heart, Injector is simply a dictionary for mapping types to things that create instances of those types. This could be as simple as:

{str: 'an instance of a string'}

For those new to dependency-injection and/or Guice, though, some of the terminology used may not be obvious.

Provider¶

A means of providing an instance of a type. Built-in providers include:

ClassProvider - creates a new instance from a class
InstanceProvider - returns an existing instance directly
CallableProvider - provides an instance by calling a function

In order to create custom provider you need to subclass Provider and override its get() method.

Scope¶

By default, providers are executed each time an instance is required. Scopes allow this behaviour to be customised. For example, SingletonScope (typically used through the class decorator singleton), can be used to always provide the same instance of a class.

Other examples of where scopes might be a threading scope, where instances are provided per-thread, or a request scope, where instances are provided per-HTTP-request.

The default scope is NoScope.

See also

Scopes

Binding¶

A binding is the mapping of a unique binding key to a corresponding provider. For example:

>>> from injector import InstanceProvider
>>> bindings = {
...   (Name, None): InstanceProvider('Sherlock'),
...   (Description, None): InstanceProvider('A man of astounding insight'),
... }

Binder¶

The Binder is simply a convenient wrapper around the dictionary that maps types to providers. It provides methods that make declaring bindings easier.

Module¶

A Module configures bindings. It provides methods that simplify the process of binding a key to a provider. For example the above bindings would be created with:

>>> from injector import Module
>>> class MyModule(Module):
...     def configure(self, binder):
...         binder.bind(Name, to='Sherlock')
...         binder.bind(Description, to='A man of astounding insight')

For more complex instance construction, methods decorated with @provider will be called to resolve binding keys:

>>> from injector import provider
>>> class MyModule(Module):
...     def configure(self, binder):
...         binder.bind(Name, to='Sherlock')
...
...     @provider
...     def describe(self) -> Description:
...         return 'A man of astounding insight (at %s)' % time.time()

Injection¶

Injection is the process of providing an instance of a type, to a method that uses that instance. It is achieved with the inject decorator. Keyword arguments to inject define which arguments in its decorated method should be injected, and with what.

Here is an example of injection on a module provider method, and on the constructor of a normal class:

from injector import inject

class User:
    @inject
    def __init__(self, name: Name, description: Description):
        self.name = name
        self.description = description


class UserModule(Module):
    def configure(self, binder):
       binder.bind(User)


class UserAttributeModule(Module):
    def configure(self, binder):
        binder.bind(Name, to='Sherlock')

    @provider
    def describe(self, name: Name) -> Description:
        return '%s is a man of astounding insight' % name

Injector¶

The Injector brings everything together. It takes a list of Module s, and configures them with a binder, effectively creating a dependency graph:

from injector import Injector
injector = Injector([UserModule(), UserAttributeModule()])

You can also pass classes instead of instances to Injector, it will instantiate them for you:

injector = Injector([UserModule, UserAttributeModule])

The injector can then be used to acquire instances of a type, either directly:

>>> injector.get(Name)
'Sherlock'
>>> injector.get(Description)
'Sherlock is a man of astounding insight'

Or transitively:

>>> user = injector.get(User)
>>> isinstance(user, User)
True
>>> user.name
'Sherlock'
>>> user.description
'Sherlock is a man of astounding insight'

Assisted injection¶

Sometimes there are classes that have injectable and non-injectable parameters in their constructors. Let’s have for example:

class Database: pass


class User:
    def __init__(self, name):
        self.name = name


class UserUpdater:
    def __init__(self, db: Database, user):
        pass

You may want to have database connection db injected into UserUpdater constructor, but in the same time provide user object by yourself, and assuming that user object is a value object and there’s many users in your application it doesn’t make much sense to inject objects of class User.

In this situation there’s technique called Assisted injection:

from injector import ClassAssistedBuilder
injector = Injector()
builder = injector.get(ClassAssistedBuilder[UserUpdater])
user = User('John')
user_updater = builder.build(user=user)

This way we don’t get UserUpdater directly but rather a builder object. Such builder has build(**kwargs) method which takes non-injectable parameters, combines them with injectable dependencies of UserUpdater and calls UserUpdater initializer using all of them.

AssistedBuilder[T] and ClassAssistedBuilder[T] are injectable just as anything else, if you need instance of it you just ask for it like that:

class NeedsUserUpdater:
    @inject
    def __init__(self, builder: ClassAssistedBuilder[UserUpdater]):
        self.updater_builder = builder

    def method(self):
        updater = self.updater_builder.build(user=None)

ClassAssistedBuilder means it’ll construct a concrete class and no bindings will be used.

If you want to follow bindings and construct class pointed to by a key you use AssistedBuilder and can do it like this:

>>> DB = Key('DB')
>>> class DBImplementation:
...     def __init__(self, uri):
...         pass
...
>>> def configure(binder):
...     binder.bind(DB, to=DBImplementation)
...
>>> injector = Injector(configure)
>>> builder = injector.get(AssistedBuilder[DB])
>>> isinstance(builder.build(uri='x'), DBImplementation)
True

Child injectors¶

Concept similar to Guice’s child injectors is supported by Injector. This way you can have one injector that inherits bindings from other injector (parent) but these bindings can be overriden in it and it doesn’t affect parent injector bindings:

>>> def configure_parent(binder):
...     binder.bind(str, to='asd')
...     binder.bind(int, to=42)
...
>>> def configure_child(binder):
...     binder.bind(str, to='qwe')
...
>>> parent = Injector(configure_parent)
>>> child = parent.create_child_injector(configure_child)
>>> parent.get(str), parent.get(int)
('asd', 42)
>>> child.get(str), child.get(int)
('qwe', 42)

Note: Default scopes are bound only to root injector. Binding them manually to child injectors will result in unexpected behaviour. Note 2: Once a binding key is present in parent injector scope (like singleton scope), provider saved there takes predecence when binding is overridden in child injector in the same scope. This behaviour is subject to change:

>>> def configure_parent(binder):
...     binder.bind(str, to='asd', scope=singleton)
...
>>> def configure_child(binder):
...     binder.bind(str, to='qwe', scope=singleton)
...
>>> parent = Injector(configure_parent)
>>> child = parent.create_child_injector(configure_child)
>>> child.get(str) # this behaves as expected
'qwe'
>>> parent.get(str) # wat
'qwe'

Testing with Injector¶

When you use unit test framework such as unittest2 or nose you can also profit from injector. However, manually creating injectors and test classes can be quite annoying. There is, however, with_injector method decorator which has parameters just as Injector construtor and installes configured injector into class instance on the time of method call:

import unittest
from injector import Module, with_injector, inject

class UsernameModule(Module):
    def configure(self, binder):
        binder.bind(str, 'Maria')

class TestSomethingClass(unittest.TestCase):
    @with_injector(UsernameModule())
    def setUp(self):
        pass

    @inject
    def test_username(self, username: str):
        self.assertEqual(username, 'Maria')

Each method call re-initializes Injector - if you want to you can also put with_injector() decorator on class constructor.

After such call all inject()-decorated methods will work just as you’d expect them to work.

Scopes¶

Singletons¶

Singletons are declared by binding them in the SingletonScope. This can be done in three ways:

Decorating the class with @singleton.
Decorating a @provider decorated Module method with @singleton.
Explicitly calling binder.bind(X, scope=singleton).

A (redundant) example showing all three methods:

@singleton
class Thing: pass
class ThingModule(Module):
    def configure(self, binder):
        binder.bind(Thing, scope=singleton)
    @singleton
    @provider
    def provide_thing(self) -> Thing:
        return Thing()

Implementing new Scopes¶

In the above description of scopes, we glossed over a lot of detail. In particular, how one would go about implementing our own scopes.

Basically, there are two steps. First, subclass Scope and implement Scope.get:

from injector import Scope
class CustomScope(Scope):
    def get(self, key, provider):
        return provider

Then create a global instance of ScopeDecorator to allow classes to be easily annotated with your scope:

from injector import ScopeDecorator
customscope = ScopeDecorator(CustomScope)

This can be used like so:

@customscope
class MyClass:
    pass

Scopes are bound in modules with the Binder.bind_scope() method:

class MyModule(Module):
    def configure(self, binder):
        binder.bind_scope(CustomScope)

Scopes can be retrieved from the injector, as with any other instance. They are singletons across the life of the injector:

>>> injector = Injector([MyModule()])
>>> injector.get(CustomScope) is injector.get(CustomScope)
True

For scopes with a transient lifetime, such as those tied to HTTP requests, the usual solution is to use a thread or greenlet-local cache inside the scope. The scope is “entered” in some low-level code by calling a method on the scope instance that creates this cache. Once the request is complete, the scope is “left” and the cache cleared.

Logging¶

Injector uses standard logging module, the logger name is injector.

By default injector logger is not configured to print logs anywhere.

To enable get() tracing (and some other useful information) you need to set injector logger level to DEBUG. You can do that by executing:

import logging

logging.getLogger('injector').setLevel(logging.DEBUG)

or by configuring logging module in any other way.

Injector API reference¶

Note

Unless specified otherwise, instance methods are not thread safe.

The following functions are thread safe:

Injector.get()
injection provided by inject() decorator (please note, however, that it doesn’t say anything about decorated function thread safety)

Injector - Python dependency injection framework, inspired by Guice

copyright:	2012 by Alec Thomas
license:	BSD

class injector.Binder(injector: injector.Injector, auto_bind: bool = True, parent: Optional[injector.Binder] = None)¶

Bases: object

Bind interfaces to implementations.

Note

This class is instantiated internally for you and there’s no need to instantiate it on your own.

bind(interface: Type[T], to: Union[None, T, Callable[[...], T], injector.Provider[~T][T]] = None, scope: Union[None, Type[Scope], ScopeDecorator] = None) → None¶

Bind an interface to an implementation.

Binding T to an instance of T like

binder.bind(A, to=A('some', 'thing'))

is, for convenience, a shortcut for

binder.bind(A, to=InstanceProvider(A('some', 'thing'))).

Likewise, binding to a callable like

binder.bind(A, to=some_callable)

is a shortcut for

binder.bind(A, to=CallableProvider(some_callable))

and, as such, if some_callable there has any annotated parameters they’ll be provided automatically without having to use inject() or Inject with the callable.

typing.List and typing.Dict instances are reserved for multibindings and trying to bind them here will result in an error (use multibind() instead):

binder.bind(List[str], to=['hello', 'there'])  # Error

Parameters:	interface – Type to bind. to – Instance or class to bind to, or an instance of `Provider` subclass. scope – Optional `Scope` in which to bind.

install(module: Union[Callable[[Binder], None], Module, Type[Module]]) → None¶

Install a module into this binder.

In this context the module is one of the following:

function taking the Binder as it’s only parameter

def configure(binder):
    bind(str, to='s')

binder.install(configure)

instance of Module (instance of it’s subclass counts)

class MyModule(Module):
    def configure(self, binder):
        binder.bind(str, to='s')

binder.install(MyModule())

subclass of Module - the subclass needs to be instantiable so if it expects any parameters they need to be injected
```
binder.install(MyModule)
```

multibind(interface: type, to: Any, scope: Union[ScopeDecorator, Type[Scope]] = None) → None¶

Creates or extends a multi-binding.

A multi-binding contributes values to a list or to a dictionary. For example:

binder.multibind(List[str], to=['some', 'strings'])
binder.multibind(List[str], to=['other', 'strings'])
injector.get(List[str])  # ['some', 'strings', 'other', 'strings']

binder.multibind(Dict[str, int], to={'key': 11})
binder.multibind(Dict[str, int], to={'other_key': 33})
injector.get(Dict[str, int])  # {'key': 11, 'other_key': 33}

Changed in version 0.17.0: Added support for using typing.Dict and typing.List instances as interfaces. Deprecated support for MappingKey, SequenceKey and single-item lists and dictionaries as interfaces.

Parameters:	interface – typing.Dict or typing.List instance to bind to. to – Instance, class to bind to, or an explicit `Provider` subclass. Must provide a list or a dictionary, depending on the interface. scope – Optional Scope in which to bind.

class injector.BoundKey¶

Bases: tuple

A BoundKey provides a key to a type with pre-injected arguments.

>>> class A:
...   def __init__(self, a, b):
...     self.a = a
...     self.b = b
>>> InjectedA = BoundKey(A, a=InstanceProvider(1), b=InstanceProvider(2))
>>> injector = Injector()
>>> a = injector.get(InjectedA)
>>> a.a, a.b
(1, 2)

exception injector.CallError¶

Bases: injector.Error

Call to callable object fails.

class injector.CallableProvider(callable: Callable[[...], T])¶

Bases: injector.Provider

Provides something using a callable.

The callable is called every time new value is requested from the provider.

There’s no need to explicitly use inject() or Inject with the callable as it’s assumed that, if the callable has annotated parameters, they’re meant to be provided automatically. It wouldn’t make sense any other way, as there’s no mechanism to provide parameters to the callable at a later time, so either they’ll be injected or there’ll be a CallError.

>>> class MyClass:
...     def __init__(self, value: int) -> None:
...         self.value = value
...
>>> def factory():
...     print('providing')
...     return MyClass(42)
...
>>> def configure(binder):
...     binder.bind(MyClass, to=CallableProvider(factory))
...
>>> injector = Injector(configure)
>>> injector.get(MyClass) is injector.get(MyClass)
providing
providing
False

exception injector.CircularDependency¶

Bases: injector.Error

Circular dependency detected.

class injector.ClassProvider(cls: Type[T])¶

Bases: injector.Provider

Provides instances from a given class, created using an Injector.

exception injector.Error¶

Bases: Exception

Base exception.

injector.Inject = typing_extensions.Annotated[~InjectT, <object object>]¶

An experimental way to declare injectable dependencies utilizing a PEP 593 implementation in Python 3.9 and backported to Python 3.7+ in typing_extensions.

Those two declarations are equivalent:

@inject
def fun(t: SomeType) -> None:
    pass

def fun(t: Inject[SomeType]) -> None:
    pass

The advantage over using inject() is that if you have some noninjectable parameters it may be easier to spot what are they. Those two are equivalent:

@inject
@noninjectable('s')
def fun(t: SomeType, s: SomeOtherType) -> None:
    pass

def fun(t: Inject[SomeType], s: SomeOtherType) -> None:
    pass

See also

Function get_bindings(): A way to inspect how various injection declarations interact with each other.

New in version 0.18.0.

Note

Requires Python 3.7+.

Note

If you’re using mypy you need the version 0.750 or newer to fully type-check code using this construct.

class injector.Injector(modules: Union[Callable[[Binder], None], Module, Type[Module], Iterable[Union[Callable[[Binder], None], Module, Type[Module]]]] = None, auto_bind: bool = True, parent: Optional[injector.Injector] = None)¶

Bases: object

Parameters:	modules – Optional - a configuration module or iterable of configuration modules. Each module will be installed in current `Binder` using `Binder.install()`. Consult `Binder.install()` documentation for the details. auto_bind – Whether to automatically bind missing types. parent – Parent injector.

New in version 0.7.5: use_annotations parameter

Changed in version 0.13.0: use_annotations parameter is removed

call_with_injection(callable: Callable[[...], T], self_: Any = None, args: Any = (), kwargs: Any = {}) → T¶

Call a callable and provide it’s dependencies if needed.

Parameters:	self – Instance of a class callable belongs to if it’s a method, None otherwise. args (tuple of objects) – Arguments to pass to callable. kwargs (dict of string -> object) – Keyword arguments to pass to callable.
Returns:	Value returned by callable.

create_object(cls: Type[T], additional_kwargs: Any = None) → T¶: Create a new instance, satisfying any dependencies on cls.

get(interface: Type[T], scope: Union[injector.ScopeDecorator, Type[injector.Scope]] = None) → T¶

Get an instance of the given interface.

Note

Although this method is part of Injector’s public interface it’s meant to be used in limited set of circumstances.

For example, to create some kind of root object (application object) of your application (note that only one get call is needed, inside the Application class and any of its dependencies inject() can and should be used):

class Application:

    @inject
    def __init__(self, dep1: Dep1, dep2: Dep2):
        self.dep1 = dep1
        self.dep2 = dep2

    def run(self):
        self.dep1.something()

injector = Injector(configuration)
application = injector.get(Application)
application.run()

Parameters:	interface – Interface whose implementation we want. scope – Class of the Scope in which to resolve.
Returns:	An implementation of interface.

class injector.InstanceProvider(instance: T)¶

Bases: injector.Provider

Provide a specific instance.

>>> class MyType:
...     def __init__(self):
...         self.contents = []
>>> def configure(binder):
...     binder.bind(MyType, to=InstanceProvider(MyType()))
...
>>> injector = Injector(configure)
>>> injector.get(MyType) is injector.get(MyType)
True
>>> injector.get(MyType).contents.append('x')
>>> injector.get(MyType).contents
['x']

class injector.Module¶

Bases: object

Configures injector and providers.

configure(binder: injector.Binder) → None¶: Override to configure bindings.

injector.NoInject = typing_extensions.Annotated[~InjectT, <object object>]¶

An experimental way to declare noninjectable dependencies utilizing a PEP 593 implementation in Python 3.9 and backported to Python 3.7+ in typing_extensions.

Since inject() declares all function’s parameters to be injectable there needs to be a way to opt out of it. This has been provided by noninjectable() but noninjectable suffers from two issues:

You need to repeat the parameter name
The declaration may be relatively distance in space from the actual parameter declaration, thus hindering readability

NoInject solves both of those concerns, for example (those two declarations are equivalent):

@inject
@noninjectable('b')
def fun(a: TypeA, b: TypeB) -> None:
    pass

@inject
def fun(a: TypeA, b: NoInject[TypeB]) -> None:
    pass

See also

Function get_bindings(): A way to inspect how various injection declarations interact with each other.

New in version 0.18.0.

Note

Requires Python 3.7+.

Note

If you’re using mypy you need the version 0.750 or newer to fully type-check code using this construct.

class injector.NoScope(injector: injector.Injector)¶

Bases: injector.Scope

An unscoped provider.

class injector.Provider¶

Bases: typing.Generic

Provides class instances.

class injector.ProviderOf(injector: injector.Injector, interface: Type[T])¶

Bases: typing.Generic

Can be used to get a provider of an interface, for example:

>>> def provide_int():
...     print('providing')
...     return 123
>>>
>>> def configure(binder):
...     binder.bind(int, to=provide_int)
>>>
>>> injector = Injector(configure)
>>> provider = injector.get(ProviderOf[int])
>>> value = provider.get()
providing
>>> value
123

get() → T¶: Get an implementation for the specified interface.

class injector.Scope(injector: injector.Injector)¶

Bases: object

A Scope looks up the Provider for a binding.

By default (ie. NoScope ) this simply returns the default Provider .

configure() → None¶: Configure the scope.

get(key: Type[T], provider: injector.Provider[~T][T]) → injector.Provider[~T][T]¶

Get a Provider for a key.

Parameters:	key – The key to return a provider for. provider – The default Provider associated with the key.
Returns:	A Provider instance that can provide an instance of key.

class injector.SingletonScope(injector: injector.Injector)¶

Bases: injector.Scope

A Scope that returns a per-Injector instance for a key.

singleton can be used as a convenience class decorator.

>>> class A: pass
>>> injector = Injector()
>>> provider = ClassProvider(A)
>>> singleton = SingletonScope(injector)
>>> a = singleton.get(A, provider)
>>> b = singleton.get(A, provider)
>>> a is b
True

class injector.ThreadLocalScope(injector: injector.Injector)¶

Bases: injector.Scope

A Scope that returns a per-thread instance for a key.

exception injector.UnknownArgument¶

Bases: injector.Error

Tried to mark an unknown argument as noninjectable.

exception injector.UnknownProvider¶

Bases: injector.Error

Tried to bind to a type whose provider couldn’t be determined.

exception injector.UnsatisfiedRequirement(owner: Optional[object], interface: type)¶

Bases: injector.Error

Requirement could not be satisfied.

injector.get_bindings(callable: Callable) → Dict[str, type]¶

Get bindings of injectable parameters from a callable.

If the callable is not decorated with inject() and does not have any of its parameters declared as injectable using Inject an empty dictionary will be returned. Otherwise the returned dictionary will contain a mapping between parameter names and their types with the exception of parameters excluded from dependency injection (either with noninjectable(), NoInject or only explicit injection with Inject being used). For example:

>>> def function1(a: int) -> None:
...     pass
...
>>> get_bindings(function1)
{}

>>> @inject
... def function2(a: int) -> None:
...     pass
...
>>> get_bindings(function2)
{'a': <class 'int'>}

>>> @inject
... @noninjectable('b')
... def function3(a: int, b: str) -> None:
...     pass
...
>>> get_bindings(function3)
{'a': <class 'int'>}

>>> import sys, pytest
>>> if sys.version_info < (3, 7, 0):
...     pytest.skip('Python 3.7.0 required for sufficient Annotated support')

>>> # The simple case of no @inject but injection requested with Inject[...]
>>> def function4(a: Inject[int], b: str) -> None:
...     pass
...
>>> get_bindings(function4)
{'a': <class 'int'>}

>>> # Using @inject with Inject is redundant but it should not break anything
>>> @inject
... def function5(a: Inject[int], b: str) -> None:
...     pass
...
>>> get_bindings(function5)
{'a': <class 'int'>, 'b': <class 'str'>}

>>> # We need to be able to exclude a parameter from injection with NoInject
>>> @inject
... def function6(a: int, b: NoInject[str]) -> None:
...     pass
...
>>> get_bindings(function6)
{'a': <class 'int'>}

>>> # The presence of NoInject should not trigger anything on its own
>>> def function7(a: int, b: NoInject[str]) -> None:
...     pass
...
>>> get_bindings(function7)
{}

This function is used internally so by calling it you can learn what exactly Injector is going to try to provide to a callable.

injector.inject(constructor_or_class: ConstructorOrClassT) → ConstructorOrClassT¶

Decorator declaring parameters to be injected.

eg.

>>> class A:
...     @inject
...     def __init__(self, number: int, name: str):
...         print([number, name])
...
>>> def configure(binder):
...     binder.bind(A)
...     binder.bind(int, to=123)
...     binder.bind(str, to='Bob')

Use the Injector to get a new instance of A:

>>> a = Injector(configure).get(A)
[123, 'Bob']

As a convenience one can decorate a class itself:

@inject
class B:
    def __init__(self, dependency: Dependency):
        self.dependency = dependency

This is equivalent to decorating its constructor. In particular this provides integration with dataclasses (the order of decorator application is important here):

@inject
@dataclass
class C:
    dependency: Dependency

Note

This decorator is to be used on class constructors (or, as a convenience, on classes). Using it on non-constructor methods worked in the past but it was an implementation detail rather than a design decision.

Third party libraries may, however, provide support for injecting dependencies into non-constructor methods or free functions in one form or another.

See also

Generic type Inject: A more explicit way to declare parameters as injectable.
Function get_bindings(): A way to inspect how various injection declarations interact with each other.

Changed in version 0.16.2: (Re)added support for decorating classes with @inject.

injector.is_decorated_with_inject(function: Callable[[...], Any]) → bool¶

See if given callable is declared to want some dependencies injected.

Example use:

>>> def fun(i: int) -> str:
...     return str(i)

>>> is_decorated_with_inject(fun)
False
>>>
>>> @inject
... def fun2(i: int) -> str:
...     return str(i)

>>> is_decorated_with_inject(fun2)
True

injector.multiprovider(function: CallableT) → CallableT¶

Like provider(), but for multibindings. Example usage:

class MyModule(Module):
    @multiprovider
    def provide_strs(self) -> List[str]:
        return ['str1']

class OtherModule(Module):
    @multiprovider
    def provide_strs_also(self) -> List[str]:
        return ['str2']

Injector([MyModule, OtherModule]).get(List[str])  # ['str1', 'str2']

See also

Generic type NoInject: A nicer way to declare parameters as noninjectable.
Function get_bindings(): A way to inspect how various injection declarations interact with each other.

injector.provider(function: CallableT) → CallableT¶

Decorator for Module methods, registering a provider of a type.

>>> class MyModule(Module):
...   @provider
...   def provide_name(self) -> str:
...       return 'Bob'

@provider-decoration implies @inject so you can omit it and things will work just the same:

>>> class MyModule2(Module):
...     def configure(self, binder):
...         binder.bind(int, to=654)
...
...     @provider
...     def provide_str(self, i: int) -> str:
...         return str(i)
...
>>> injector = Injector(MyModule2)
>>> injector.get(str)
'654'

Frequently Asked Questions¶

If I use `inject()` or scope decorators on my classess will I be able to create instances of them without using Injector?¶

Yes. Scope decorators don’t change the way you can construct your class instances without Injector interaction.

I’m calling this method (/function/class) but I’m getting “TypeError: XXX() takes exactly X arguments (Y given)”¶

Example code:

class X:
    @inject
    def __init__(self, s: str):
        self.s = s

def configure(binder):
    binder.bind(s, to='some string')

injector = Injector(configure)
x = X()

Result?

TypeError: __init__() takes exactly 2 arguments (1 given)

Reason? There’s no global state that Injector modifies when it’s instantiated and configured. Its whole knowledge about bindings etc. is stored in itself. Moreover inject() will not make dependencies appear out of thin air when you for example attempt to create an instance of a class manually (without Injector’s help) - there’s no global state @inject decorated methods can access.

In order for X to be able to use bindings defined in @inject decoration Injector needs to be used (directly or indirectly) to create an instance of X. This means most of the time you want to just inject X where you need it, you can also use Injector.get() to obtain an instance of the class (see its documentation for usage notes).

Good and bad practices¶

Side effects¶

You should avoid creating side effects in your modules for two reasons:

Side effects will make it more difficult to test a module if you want to do it
Modules expose a way to acquire some resource but they don’t provide any way to release it. If, for example, your module connects to a remote server while creating a service you have no way of closing that connection unless the service exposes it.

Injecting into constructors vs injecting into other methods¶

Note

Injector 0.11+ doesn’t support injecting into non-constructor methods, this section is kept for historical reasons.

Note

Injector 0.11 deprecates using @inject with keyword arguments to declare bindings, this section remains unchanged for historical reasons.

In general you should prefer injecting into constructors to injecting into other methods because:

it can expose potential issues earlier (at object construction time rather than at the method call)

it exposes class’ dependencies more openly. Constructor injection:

class Service1(object):
    @inject(http_client=HTTP)
    def __init__(self, http_client):
        self.http_client = http_client
        # some other code

    # tens or hundreds lines of code

    def method(self):
        # do something
        pass

Regular method injection:

class Service2(object):
    def __init__(self):
        # some other code

    # tens or hundreds lines of code

    @inject(http_client=HTTP)
    def method(self, http_client):
        # do something
        pass

In first case you know all the dependencies by looking at the class’ constructor, in the second you don’t know about HTTP dependency until you see the method definition.

Slightly different approach is suggested when it comes to Injector modules - in this case injecting into their constructors (or configure methods) would make the injection process dependent on the order of passing modules to Injector and therefore quite fragile. See this code sample:

A = Key('A')
B = Key('B')

class ModuleA(Module):
    @inject(a=A)
    def configure(self, binder, a):
        pass

class ModuleB(Module):
    @inject(b=B)
    def __init__(self, b):
        pass

class ModuleC(Module):
    def configure(self, binder):
        binder.bind(A, to='a')
        binder.bind(B, to='b')


# error, at the time of ModuleA processing A is unbound
Injector([ModuleA, ModuleC])

# error, at the time of ModuleB processing B is unbound
Injector([ModuleB, ModuleC])

# no error this time
Injector([ModuleC, ModuleA, ModuleB])

Doing too much in modules and/or providers¶

An implementation detail of Injector: Injector and accompanying classes are protected by a lock to make them thread safe. This has a downside though: in general only one thread can use dependency injection at any given moment.

In best case scenario you “only” slow other threads’ dependency injection down. In worst case scenario (performing blocking calls without timeouts) you can deadlock whole application.

It is advised to avoid performing any IO, particularly without a timeout set, inside modules code.

As an illustration:

from threading import Thread
from time import sleep

from injector import inject, Injector, Module, provider

class A: pass
class SubA(A): pass
class B: pass


class BadModule(Module):
    @provider
    def provide_a(self, suba: SubA) -> A:
        return suba

    @provider
    def provide_suba(self) -> SubA:
        print('Providing SubA...')
        while True:
            print('Sleeping...')
            sleep(1)

        # This never executes
        return SubA()

    @provider
    def provide_b(self) -> B:
        return B()


injector = Injector([BadModule])

thread = Thread(target=lambda: injector.get(A))

# to make sure the thread doesn't keep the application alive
thread.daemon = True
thread.start()

# This will never finish
injector.get(B)
print('Got B')

Here’s the output of the application:

Providing SubA...
Sleeping...
Sleeping...
Sleeping...
(...)

Injecting Injector and abusing Injector.get¶

Sometimes code like this is written:

class A:
    pass

class B:
    pass

class C:
    @inject
    def __init__(self, injector: Injector):
        self.a = injector.get(A)
        self.b = injector.get(B)

It is advised to use the following pattern instead:

class A:
    pass

class B:
    pass

class C:
    @inject
    def __init__(self, a: A, b: B):
        self.a = a
        self.b = b

The second form has the benefits of:

expressing clearly what the dependencies of C are
making testing of the C class easier - you can provide the dependencies (whether they are mocks or not) directly, instead of having to mock Injector and make the mock handle Injector.get() calls
following the common practice and being easier to understand

Injecting dependencies only to pass them somewhere else¶

A pattern similar to the one below can emerge:

class A:
    pass

class B:
    def __init__(self, a):
        self.a = a

class C:
    @inject
    def __init__(self, a: A):
        self.b = B(a)

Class C in this example has the responsibility of gathering dependencies of class B and constructing an object of type B, there may be a valid reason for it but in general it defeats the purpose of using Injector and should be avoided.

The appropriate pattern is:

class A:
    pass

class B:
    @inject
    def __init__(self, a: A):
        self.a = a

class C:
    @inject
    def __init__(self, b: B):
        self.b = b

Welcome to Injector’s documentation!¶

Introduction¶

Quick start¶

Contents¶

Injector Change Log¶

0.20.1¶

0.20.0¶

0.19.0¶

0.18.4¶

0.18.3¶

0.18.2¶

0.18.1¶

0.18.0¶

0.17.0¶

0.16.2¶

0.16.1¶

0.16.0¶

0.15.0¶

0.14.1¶

0.14.0¶

0.13.4¶

0.13.3¶

0.13.2¶

0.13.1¶

0.13.0¶

0.12.0¶

0.11.1¶

0.11.0¶

0.10.1¶

0.10.0¶

0.9.1¶

0.9.0¶

0.8.0¶

0.7.9¶

0.7.8¶

0.7.7¶

0.7.6¶

0.7.5¶

Terminology¶

Provider¶

Scope¶

Binding¶

Binder¶

Module¶

Injection¶

Injector¶

Assisted injection¶

Child injectors¶

Testing with Injector¶

Scopes¶

Singletons¶

Implementing new Scopes¶

Logging¶

Injector API reference¶

Frequently Asked Questions¶

If I use inject() or scope decorators on my classess will I be able to create instances of them without using Injector?¶

I’m calling this method (/function/class) but I’m getting “TypeError: XXX() takes exactly X arguments (Y given)”¶

Good and bad practices¶

Side effects¶

Injecting into constructors vs injecting into other methods¶

Doing too much in modules and/or providers¶

Injecting Injector and abusing Injector.get¶

Injecting dependencies only to pass them somewhere else¶

If I use `inject()` or scope decorators on my classess will I be able to create instances of them without using Injector?¶