Overall codestyle improvement proposal

[Tapeline]

Was looking through the Dishka's sources, I think there are some things we can improve in codestyle.

First of all, I think we should ignore less Ruff warnings. In particular:

• TRY003 (Avoid specifying long messages outside the exception class)
  The reasoning provided in Ruff docs is good enough:

  By formatting an exception message at the raise site, the exception class becomes less reusable, and may now raise inconsistent messages depending on where it is raised.

  If the exception message is instead defined within the exception class, it will be consistent across all raise invocations

  Creating different exception classes also will improve readability of the code.

• TC00X (Move library into type-checking block)

  As Dishka is a framework, it should do its best to be as fast as possible. Imports, after all, do cost something, so I think we should do what TC00X warnings suggest: move imports of modules that are used solely for type-checking into a if TYPE_CHECKING block.

  Unused imports add a performance overhead at runtime, and risk creating import cycles. If an import is only used in typing-only contexts, it can instead be imported conditionally under an if TYPE_CHECKING: block to minimize runtime overhead.

  (however, don't really know how much of a big deal that is)

• PLR0913 (Too many arguments)
  This check is generally okay, but there are some places that require a lot of arguments. It's better to exclude them explicitly, that to exclude the whole check.

• SIM114 (Merge if branches with identical bodies)

  Code repetition is bad. Did not find any reasoning behind exclusion of that check. I think we should definetly bring it back. Moreover, it occurrs only 3-4 times in the whole codebase, so I think it won't be a pain to fix.

• PLW2901 (Redefinition of a name in loop)

  Also generally a good check. As with PLR0913, we should not ignore the whole check, but rather some places where it's okay to reassign the variable.

• UP038, SIM103 - their exclusion/inclusion does not affect the results of linter in any way. They should definetly be re-included.

The second point is, we can benefit of making use of wemake-python-styleguide linter. Major issues which it reveals and we totally should address are:

• Too complex lines, functions and modules.
  Even alone they dramatically drop the readability and, as a consequence, the ability of new contributors to onboard easily. But here, combined with lack of thorough code documentation, they become even worse.

• Code overuse.
  I think we can all agree that, again, code repetition is bad. We should definetly fix that.

• Some weird code (like checking types with type(...) is ...).
  There is no doubt that coding in general and creating that kind of a framework especially requires some magic and weird code in some places. But the point is: it should be documented and provided with a reasoning.

• and much much more small and medium-sized issues, fixing which will improve the codebase.

The final thought is that we can add more docstrings, so the project becomes more friendly to beginning contributors.

In conclusion,
Main two goals of this proposal are:

1. Improve codebase so it's easier for new contributors to onboard.

2. Improve codebase so there is less space for bugs and (potentially) performance issues.

I find them very important, especially for an open-source project.

Hope that @Tishka17 will agree with me. Although I definetly would participate in making this proposal come true, these changes could not be done without thorough consulting and discussion with the creator and "ideologist" of the framework.

Looking forward to your comments about this.

[Tishka17]

TRY003 - ok, if done carefully. We do not want to introduce long living references to many objects
TC00X - awful thing, never use it. It makes runtime work differently from typechecker
PLR0913 - useful euristic, which can be used to find bad places, should not block CI, but we can discuss specific places
SIM114 - identitcal by code != identical by meaning. Can be nice tool to examine code, but should not block CI
PLW2901 - nice, let's enable in whole, but disable in some plaves, sometimes we need it as a hack
UP038 - useless thing, which only affects perfomance and brings nothing useful
SIM103 - can reduce redability, we can discuss every specific case