Replies: 1 comment
-
|
You’re asking me for a value judgement here, not a feature, right? At the top, I would say that my gut feeling is that if you end up with circular imports that can’t be fixed using That said, I mean why not. It gives you a finer-grained control for replacing parts of your application than monkeypatching. And we shouldn’t forget that in Python modules are often used for things that other languages use classes for. I would advice, though, to more think about what those parts do and hide them behind an interface? Authn/z is a Classic ex alle for something someone might want to be plugable; be it just in dev vs prod. |
Beta Was this translation helpful? Give feedback.
-
I was wondering about the possibility of having a large app's packages expose a public API via a service class registered with svcs. Imagine a separate for authn, authz, billing, audit logs, and so on. The biggest pain we are trying to solve currently is how prone such a large app is to circular imports.
So I was thinking, using svcs is kinda similar to using inlined import statements, which is a way to solve circular imports. What do you think about this concept? Is it feasible with regard to circular dependencies as svcs is implemented?
Tbh I also feel like the idea of a class being exposed with public utils is easier to enforce and lends itself well to documentation, compared to accomplishing the same with modules.
Beta Was this translation helpful? Give feedback.
All reactions