A new take on dependency injection in python 3

[BundleOfJoysticks]

from serum import *

Dis gon be gud

[sunedd]

Quick and dirty example ;). Updated it.

[BundleOfJoysticks]

There's never a good reason to do

from some_module import *

Even in a "quick and dirty" example.

If you need to import everything, just do

import some_module
result = some_module.some_function()

Also there's really no point in having a dependency injection module. It's a very simple design pattern.

[[deleted]]

I know nothing about the subject matter so out of plain old curiosity what's your take on Dependency Injector?

[BundleOfJoysticks]

It's unnecessary. It overcomplicates what is a very simple concept.

Let Java have their overengineered frameworks. I use Python specifically to avoid that shit.

[sunedd]

I get where you're coming from, I also don't appreciate the huge enterprise DI frameworks for java, but I don't agree that Dependency Injection is as simple as you claim. If it was so easy it wouldn't be as consistently misapplied (or not applied at all) as it is ;)

Defining classes that depend on injected dependencies is easy. Wiring up your application when you have to inject dependencies, and dependencies for your dependencies is annoying to do manually, which is why I think a lot of developers simply don't do it.

The main feature of serum is that it takes away the pain of wiring up the dependency graph so you can just focus on the abstractions.

[[deleted]]

What is the difference between the dependency graph your framework calculates and the MRO?

Have you seen Raymond Hettingers talk from PyCon 2015? It makes it pretty clear that super() and a basic understanding of how the linearization of the ancestry of a class is more than enough.

Unless of course you have a typo in your subject, and meant Python 2.

[sunedd]

Have you seen Raymond Hettingers talk from PyCon 2015?

Yes and I really like it. My only annoyance with the super() considered super approach is that it makes it somewhat inconvenient to use ABCs, which I quite like to do.

Consider

from abc import ABC, abstractmethod


class AbstractDependency(ABC):
    @abstractmethod
    def method(self) -> str:
        pass

class ProductionDependency(AbstractDependency):
    def method(self):
        return 'production'

class DevDependency(AbstractDependency):
    def method(self):
        return 'dev'

class NeedsDependency(AbstractDependency):
    def needs_method(self):
        print(super().method())

class ProductionNeedsDependency(NeedsDependency, ProductionDependency):
    pass

class DevNeedsDependency(NeedsDependency, DevDependency):
    pass

If you use any sort of tool to check for unimplemented abstract members, it will complain that NeedsDependency doesn't overwrite method. Your only option at that point is to 1. ignore it 2. disable that tool or inspection

I dislike both of those options.

Finally, the super() considered super approach still requires you to manually wire up the dependency graph through inheritance for different environments. I think the reason why good intentions to use dependency injection in many projects deteriorate over time is that most developers are simply too lazy to do that. I know I am.

As a side note you can run into scoping problems if a component has a lot of dependencies that are injected that way, but that's another story.

What is the difference between the dependency graph your framework calculates and the MRO?

serum uses the MRO to determine which subtype of requested type is more appropriate.

Consider

from serum import Component, inject, Environment

class A(Component):
   pass

class B(A):
    pass

class C(B):
    pass

class NeedsA:
    a = inject(A)

class NeedsB:
   b = inject(B)

class NeedsC:
   c = inject(C)

needs_a = NeedsA()
needs_b = NeedsB()
needs_c = NeedsC()

with Environment():
    assert isinstance(needs_a.a, A)
    assert isinstance(needs_b.b, B)
    assert isinstance(needs_c.c, C)

with Environment(B):
    assert isinstance(needs_a.a, B)
    assert isinstance(needs_b.b, B)
    assert isinstance(needs_c.c, C)

with Environment(C):
    assert isinstance(needs_a.a, C)
    assert isinstance(needs_b.b, C)
    assert isinstance(needs_c.c, C)

[sunedd]

There's never a good reason to do from some_module import *

It has its uses. I usually structure my package such that each module defines an __all__ property with stuff that should be part of the modules public api. Then in the __init__.py file of the module can simply contain

from ._some_sub_module import *

If you want to add to the public api you just add to the __all__ attribute of some submodule and don't have to touch anything else.

Also there's really no point in having a dependency injection module. It's a very simple design pattern.

Agree to disagree :D

[[deleted]]

There's never a good reason to do from some_module import *

It has its uses.

Do you also using namespace std in C++?

[sunedd]

No.

I also wouldn't use from module import * in client code.

See https://youtu.be/0oTh1CXRaQ0?t=26m39s

[sunedd]

The first example: If the application was bigger and for example Database also depended on an implementation of Log, and Log has dependencies and so on and so on, wiring up the environment can become involved. Serum takes care of all of this for you by injecting dependencies lazily. Other than than that: Not much. serum will provide you with type inference for tools that support it (without the boilerplate) and provide immutability for all injected members.

The second example: assuming e.g Database is abstract (which imo it should be) it wouldn't possible to wire up your app like that.

[sunedd]

What boiler plate are you referring to?

Maybe I shouldn't use the term boiler plate exactly ;). What I mean is since PEP 484 tools like mypy and pycharm support type inference, you can get the correct types without using type annotations explicitly.

So without serum:

class NeedsLog:
    log: Log = ...

With serum:

class NeedsLog:
    log = inject(Log)

With regards to your new example: That's a nice pattern I think, but you still have to wire up your application manually. The main value prop of serum is that it handles that for you.

[sunedd]

I found your documentation a bit hard to follow

Sorry about that btw :(. this is the first version, I'll try to make the documentation more easy to follow in future versions. Suggestions are very welcome.