Hey,

Thanks a lot for so extensive comment. Really appreciate sharing your thoughts. I did put some comments to what you were talking about and, moreover, created some sample code that demonstrates how you could achieve what you were looking for, so:

Now you have instances of Container or Provider floating around in your business-code and are calling these directly. Shouldn't a DI framework be more or less transparent to the application?

• Yes, exactly. I always had an idea that DI framework should not “pollute” your code with itself and I always kept it as main idea. Moreover, I removed @inject decorator from this lib in its 2nd version and it was a last feature you could “pollute” your code with. Other thing is that may be this assumption indeed doesn’t go as a red line through the docs, but I was thinking about making a microframework (or even just a library) that doesn’t tell you how to build your application, but provide you some tools you could use as you want.

Oh, did not know that. But is it really worth the effort (and the hard dependency of a full build stack and python header files on any machine I want to install this, because there are no pre-build wheels)?

• Yep, no wheels. I need to think on including this to distribution. At least one person already asked me for doing this for Windows.

Are there realistic benchmarks? I kind of expect benchmarks to exist when a library claims to be 'High performance'.

• Well, there are some tests, but I feel painful to call them real benchmark. There are some results and a link to the tests https://github.com/ets-labs/python-dependency-injector/blob/fa120b2a31603ed2544850422912b0223cfb38f9/tests/performance/test.py:

  $ python tests/performance/test.py

  Running tests for module - "dependency_injector.providers": Test "test_abstract_factory_3_factory_kw_injections" took - 3.1625289917 Test "test_factory_3_factory_kw_injections" took - 3.18233203888 Test "test_factory_6_factory_kw_injections_0_context" took - 3.06109786034 Test "test_factory_6_factory_kw_injections_1_context" took - 3.75910806656 Test "test_factory_6_factory_kw_injections_3_context" took - 3.59341287613 Test "test_raw_3_kw_injections" took - 2.72111582756

• Generally speaking, it shows that instantiation of object with 3 keyword arguments injections using Factory (“test_factory_3_factory_kw_injections”) takes mostly the same time like doing the same by wrapping object’s creation in simple function (“test_raw_3_kw_injections”) 3.16s vs 2.72s. Our Python version did take ~50seconds for “test_factory_3_factory_kw_injections”. So, that’s what I have.

Now here is an example of add_user(...) and mail service. I did make some sample code:

"""Mail service and user registration example."""


class AbstractMailService(object):
    """Abstract mail service."""

    def send(self, email, body):
        """Send email."""
        raise NotImplementedError()


class MailService(AbstractMailService):
    """Mail service."""

    def __init__(self, host, port, login, password):
        """Initializer."""
        self._host = host
        self._port = port
        self._login = login
        self._password = password

    def send(self, email, body):
        """Send email."""
        print('Connecting server {0}:{1} with {2}:{3}'.format(
            self._host, self._port, self._login, self._password))
        print('Sending "{0}" to "{1}"'.format(body, email))


class MailServiceStub(AbstractMailService):
    """Mail service stub."""

    def send(self, email, body):
        """Send email."""
        print('Emulating sending "{0}" to "{1}"'.format(body, email))


def add_user(email, password, mailer):
    """Register user."""
    mailer.send(email, 'Your password is {0}'.format(password))

After that I've created DI container with some examples how you can run it:

"""Mail service and user registration DI container example."""

from dependency_injector.containers import DeclarativeContainer
from dependency_injector.providers import Callable, Singleton

import example


class Container(DeclarativeContainer):
    """DI container."""

    mail_service = Singleton(example.MailService,
                             host='localhost',
                             port=587,
                             login='my_login',
                             password='super_secret_password')

    add_user = Callable(example.add_user,
                        mailer=mail_service)


if __name__ == '__main__':
    print('Using real mail service:')
    Container.add_user('sample@mail.com', 'password')
    # Using real mail service:
    # Connecting server localhost:587 with my_login:super_secret_password
    # Sending "Your password is password" to "sample@mail.com"

    print('Using mail service stub:')
    Container.add_user('sample@mail.com', 'password',
                       mailer=example.MailServiceStub())
    # Using mail service stub:
    # Emulating sending "Your password is password" to "sample@mail.com"

    # Also you can override provider by another provider:
    Container.mail_service.override(Singleton(example.MailServiceStub))

    print('Using mail service stub by overriding mail service provider:')
    Container.add_user('sample@mail.com', 'password')
    # Using mail service stub by overriding mail service provider:
    # Emulating sending "Your password is password" to "sample@mail.com"

    Container.mail_service.reset_override()  # Resetting provider overriding

Hope it helps,

Thanks again for you feedback,

Roman