You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I consider dependency_injector over-engineered. It has many providers which look the same, but it's not clear which and when to use.
This version seems much cleaner, with less magic.
However, going through the code, I see almost no docstrings and comments. This means that one has to consult the docs (if there are docs) in hope to understand details about some providers, their arguments.
The text was updated successfully, but these errors were encountered:
Today is the first day of the release of my package and I decided to do it a little prematurely, because the only thing that hasn’t been fully worked out is the documentation.
I think your comment is fair regarding overengineering in dependency_injector. But my package contains very little code and it works the same (except that some providers, in my opinion, are not very useful)
It seems that I have sufficiently covered the code with types and the most important thing - it is very simple! So, IMO it does not need docstrings and comments. And I’ll be actively working on documentation next week, I’ll start with a description of providers and use cases
However, I would choose having docstrings over not having them. I'd love it if you could help with this while I'm busy documenting it!
I consider dependency_injector over-engineered. It has many providers which look the same, but it's not clear which and when to use.
This version seems much cleaner, with less magic.
However, going through the code, I see almost no docstrings and comments. This means that one has to consult the docs (if there are docs) in hope to understand details about some providers, their arguments.
The text was updated successfully, but these errors were encountered: