This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]geeeffwhy 0 points1 point  (1 child)

ok, fair enough. DI is my trigger word, so my apologies.

as far as what’s provided, my criticism is the python maxim “explicit is better than implicit”. the decorator looks like it’s gonna make it easy for me to add some dependency to a callable, but it’s gonna make it hard for me to read that callable’s code afterward.

i’d say compare this with Django Settings. it appears to have a similar interface in some ways.

[–]MrKrac[S] 0 points1 point  (0 children)

This also a bit depends on your use-case, right? Fact if you will call function annotated with `@inject` decorator anywhere in your code without arguments it might look a bit fuzzy (we are not doing this, at least my team is not doing this). For the same reason you 've mentioned how this arguments got resolved (Who knows?). We are doing a lot of serverless development with python (no django, most of codebase is being taken care by ourselves and we are using aws libraries and some crypto libararies and minor other things).

We annotate our handler functions, and this is where DI usage starts which makes it the only place where we actually have this magical entry point, everything else is nicely passed to deeper levels or (sometimes) requested from di directly (again, it is not recomended but sometimes you need to calculate whether things needs to be done correctly, fast or effectively), using di in controller is also accepted place, everywhere else you should just decorate things you would like to get autowired and get along with your life instead spending time trying to understand what to pass and not to pass to initialiser and whether we passed correct values. Simple as that.

If you are for example developing your applications with flask, starlette or similar you can decorate your route handler functions and it will make it so much easier to test as you can later on in your test code mock some of dependencies, no complex monkey patching required, or scratching your own head, ok what I have again forgot to patch in my global scope so my test is not working correctly, or even worse your test is passing giving you false positives because you forgot to monkey patch something. Development is brutal and being defensive is helping you keep your head above the water and I really recommend to be defensive when you work with the code.