4 ms·
The purpose is you want to use code in other modules. If you keep doing that for a while, a circular dependency will happen. This is the dumbest thing thing i
by BurningFrog 5y ago
The purpose is you want to use code in other modules.
If you keep doing that for a while, a circular dependency will happen.
This is the dumbest thing thing in Python. All other languages I know have solved it.
- chrisseaton 5y ago> The purpose is you want to use code in other modules. So put them in the same module? Circular modules don’t give you the benefits of modules, do they? Not an expert in modularity.
- BurningFrog 5y agoPutting all your code in one file does indeed solve all import problems, but creates far bigger ones. In case you didn't know, each source code file is a module in Python.
- maleldil 5y agoIf you have A -> B -> C -> A, then you need all three of A, B and C to be defined if you're going to use any one of those modules. When that's the case, the only thing you're gaining by using modules is the organisation of the file.
- BurningFrog 5y agoSure, but organizing code in files is one of the most important parts of programming!
- kortex 5y agoI've never had a circular dependency I couldn't resolve. Just organize your modules into a DAG. I have a pretty standard flow: - protocols and abcs. Depend only on builtins, this sits at the top of the hierarchy and can be used anywhere - top-level types/models, data structures. Only depends on external libraries - config and logging. Depends on pydantic, which handles all init config validation, sets up log level. Many things import this - specific class implementations, pure functions, transforms. imports from all the above - dependency-injected stuff - application logic - routers and endpoints I've had some close calls since I type check heavily, but protocols (since 3...6? 3.7 for sure) are a fantastic tool for both structuring and appeasing mypy.