-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typing infrastructure improvements #120
base: master
Are you sure you want to change the base?
Typing infrastructure improvements #120
Conversation
8efdc9e
to
b51ce09
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #120 +/- ##
==========================================
+ Coverage 88.16% 91.07% +2.90%
==========================================
Files 14 16 +2
Lines 338 336 -2
==========================================
+ Hits 298 306 +8
+ Misses 40 30 -10
|
Hi @parfeniukink, thanks! From the first read I'd say it's very nice, although I am not a huge fan of the |
Well, yeah. I agree with the btw, I think that infrastructure layer is kind of a good naming bud not for the 3-rd party package, like |
2.1. In this PR you'll find the infrastructure layer that encapsulates all the shared logic for the whole application and make it linear from modules importing perspective (now, there is no imports on the same level)
if TYPE_CHECKING:
lines are removed due to it's unnecessary. Basically this line might be useful if you have some architecture issues (circular imports) in your code but seems there is no reason to overcomplicate the project with additionalif
statement in all concrete implementations. Even thought if we decide having them in the project I would recommend usingfrom __future__ import annotations
over theif TYPE_CHECKING:
__all__
. Since the__all__
could be used to control wild imports in Python this is definitely a good way to go with in my opinion. In the old version of the code the controll of the import is on the__init__.py
which make developers to think about a couple of places to export their modules. With current approach you control your concrete SSO implementation in your single file which make the code more robust from changes perspective. Like, all the names that are allowed to be imported from this module are defined in this module itself. And, the way to import this module is defined on the level above (on the package level).So basically this is the result of the typings improvements: