Comparison to Wireup

[slykar]

Hi 👋

I was comparing the API surface of Python DI libraries and in the end I've found 2 I like: Dishka and Wireup.

Since you're already providing a comparison with other DI libraries, a comparison with one that feels very similar on the surface would be helpful.

The API surface and functionality is very similar. I've mocked exactly the same "app" with both.

One thing that caught my attention in Wireup is "compilation" which was added in v2.2.0.

I kinda like Dishka's API more, but would love a more technical comparison from someone who knows what to look at.

[Tishka17]

It is hard to keep that comparison in actual form having a big amount of libraries there.

Talking about compilation feature:
https://github.com/maldoinc/wireup/blob/v2.5.0/wireup/ioc/factory_compiler.py

it looks similar to what we have in dishka since the first public release. It is really essential for perfomance.
https://github.com/reagento/dishka/blob/1.0.0/src/dishka/factory_compiler.py

In new version (not yet release) I have rebuilt this code a lot to enable more complex feature like conditional activation
https://github.com/reagento/dishka/tree/develop/src/dishka/code_tools

[slykar]

Thanks for answering. I'm aware that the comparison was not refreshed for a long time. I imagine it must be time consuming.

It's great to know Dishka also has the code compilation.

Since you've mentioned it. I've looked at the conditional activation docs, but I wonder how does this compare to just doing an if statement in the provider's method body. In other words, could you just replace these 3 methods from this example with a match or if block while using a single provider method?

Comparing the usage of Markers to if statements would improve the clarity of the docs.

[Tishka17]

I don't think Activation featur is for everyday use (though, time will show). I consider it for applications with plugin systems of relying on multiple frameworks at the same time. In this case you can design a set of providers and have an external control of their features.
So, you define providers and set a switch (marker) for them. And then you can enable or disable it even within a single request (in this case no unneeded object will be created)

[slykar]

I see. Thanks for indulging me. Looking forward to see where it goes ;)

[Tishka17]

So, talking about code generation. Let's say we have a class, registered in container

class GatewayImplementation(Gateway):
    def __init__(self, config: Config, connection: Connection):
       ...


provider.provide(GatewayImplementation, provides=Gateway)

During preparation step we gather its dependencies as a list, store flags and so on.
If we do not run code generation here, to create this object we need to run a code like this

solved = factory.source(*(
    getter(key) for key in factory.dependencies
))
if factory.cache:
   cache[factory.provides] = solved

There are few things here which can be optimized:

1. generator expression + unpacking can be replaced with just 2 calls
2. we do not really need if as each factory is always cached or never cached.
3. Attribute lookup can be replaced with just variables

So, we can generate the code in form:

solved = GatewayImplementation(getter(key_Config), getter(key_Connection))
cache[key_GatewayImplementation] = solved
return solved

This will work much faster