How to organize the package / module dependency tree?

Question

Good morning,

I am currently writing a python library. At the moment, modules and classes are deployed in an unorganized way without sound design. When I come to a more formal release, I would like to reorganize the classes and modules so that they have a better overall design. I drew an import dependency diagram, and I planned to aggregate classes by level. In addition, I looked at some class modifications to reduce these dependencies.

What is your strategy for a good overall design of a potentially complex and complete python library? Do you have any interesting suggestions?

thanks

Update:

I really was looking for a rule of thumb. For example, suppose this case happens ( init .py is removed for clarity)

foo/bar/a.py foo/bar/b.py foo/hello/c.py foo/hello/d.py 

now if you have d.py importing bar.b and a.py importing hello.c, I consider this a bad setup. Another case would be

 foo/bar/a.py foo/bar/baz/b.py foo/bar/baz/c.py 

suppose both imports are a.py and b.py c. you have three solutions: 1) b import c, import baz.c 2) you move c to foo / bar. import a.py c, b.py import.c 3) you move somewhere else (say foo / cpackage / c.py), and then both a and b import cpackage.c

I prefer 3), but if c.py does not make any difference as a stand-alone module, for example, because you want to keep it "private" in the package panel, I would prefer to switch to 1).

There are many other similar cases. My rule is to reduce the number of dependencies and intersections at least, so to prevent a highly branched, highly intertwined installation, but I could be wrong.

Answer 1

"I drew a chart of import dependencies, and I planned to aggregate classes by level level."

Python should read like English (or any other natural language.)

Import is a first-class operator that should have real meaning. The organization of things at the level level (whatever that may be) should be clear, meaningful and obvious.

Do not make arbitrary technical groupings of classes into modules and modules into packages.

Make modules and packages obvious and logical so that the import list is obvious, simple, and logical.

"In addition, I looked at some class modifications to reduce these dependencies.

Reducing dependencies sounds technically and arbitrary. It may not be so, but it sounds like that. It is impossible to say without real examples.

Your goal is clarity.

In addition, the module and package are self-contained reuse blocks. (Not classes, class, but by itself is usually not reused). The dependency tree should reflect this. You are targeting modules that you can import neatly and cleanly into your application.

If you have many closely related modules (or alternative implementations), then packages can be used, but are used sparingly. Python libraries are relatively flat; and there is some kind of wisdom.

---

Edit

The one-way relationship between layers is an important feature. This is more about proper software design than Python. You must (1) design in layers, (2) design so that the dependencies are very strict between the layers, and then (3) implement this in Python.

Packages may not necessarily match your location. Packages can physically be a flat list of directories with dependencies expressed only through import statements.

Answer 2

The question is very vague.

You can achieve this by having basic / basic things that don't import anything from the rest of the library, and specific implementations imported here. In addition to “do not import two modules from each other during import”, you should be fine.

module1.py:

 import module2 

module2.py:

 import module1 

This will not work!

Answer 3

It depends on the project, right? For example, if you use the model-view-controller design, then your package will be structured to make 3 groups of code independent.

If you need ideas, open the directory of your sites and view some of the code in these modules to see how they are configured.

There is no right way without knowing more about the module; as Ali said, this is a vague question. You just need to analyze what you have in front of you and find out what may work better.