How to simplify utils package design details using Python's package mechanism

package mechanism

package is the set of modules, each Package should have 1 per ___.py under the root of each Package. When the interpreter finds the file in the directory, it thinks it's an Package instead of a normal directory.

As for the explanation of package mechanism, in fact, the official document has been very detailed, this article does not focus on this.

Simply put, 1 per cent per ___, if it contains 16EN__.py, is treated by Python as 1 Python package. Among them:

The thing in ___, with init__.py, will be loaded first when initializing the package sub package can also be defined in package

The original

For conceptual unity 1, we divide code writers into two roles:

Library Author Caller is API users

Sometimes we'll be 1 or 2, and sometimes we'll be both 1 and 2 (for example, if we're responsible for a larger system).

Obviously, the point of view of this article is 1 (that is, we only act as the library author and don't know who our caller is).

Initially, utils might be just one utils.py, and then the caller from utils import XXUtils That's it, there's nothing to it.

Most of the time, however, this is not the case. All Utils is in one file (up to 400 to 500 lines per source file). So our directory structure would look like this:

utils/
 __init__.py
 a_util.py
 b_util.py
 ......

How does the caller use it? from utils.a_util import AUtils

This approach assumes that the caller has a clear idea of which py file he needs. But this assumption is not always true, and it is possible that our understanding of the concept of the same one is very different. For example, utils, which you think is appropriate to call utils, and others think is appropriate to call tools, is actually the same thing.

Obviously, this imposes a mental burden on the caller. More obviously, as library authors, we have an obligation to optimize the caller's experience! Otherwise, no matter how great your Treasury is, it will be empty to play the harp if no one likes it.

HOW

Using the package mechanism wisely, you can immediately optimize the 1 experience.

Let's just write it this way with ___ 76en__.py:

__init__.py
from .a_util import AUtils
from .b_util import BUtils

The caller still USES:

from utils import AUtils, BUtils

The caller doesn't care where your implementation is, you just give me an utils namespace and make sure that all Utils are in that namespace.

To be more compliant with the PEP8 specification, as library authors, our directory structure might look like this:

utils/
 __init__.py
 _a_util.py     To the outside world ,  Only in this package Other modules are used 
 _b_util.py

application

This method applies not only to utils packages but also to exceptions packages as well as constants packages. With a lot of open source libraries, champions often use this 1 technique to optimize our experience (too often, almost every ___ of the open source libraries will have something written in

conclusion