A package’s$_{__path__}$ attribute is used during imports of its subpackages. Within the import machinery, it func- tions much the same as$_{sys.path}$ , i.e. providing a list of locations to search for modules during import. However, __path__ is typically much more constrained than$_{sys.path}$ . By definition, if a module has a$_{__path__}$ attribute, it is a package. __path__ must be an iterable of strings, but it may be empty. The same rules used for$_{sys.path}$also apply to a package’s$_{__path__}$ , and$_{sys.path_hooks}$(described below) are consulted when traversing a package’s __path__ . A package’s$_{__init__.py}$ file may set or alter the package’s$_{__path__}$ attribute, and this was typically the way namespace packages were implemented prior to PEP 420 . With the adoption of PEP 420 , namespace packages no longer need to supply$_{__init__.py}$ files containing only$_{__path__}$ manipulation code; the import machinery automatically sets$_{__path__}$ correctly for the namespace package. By default, all modules have a usable repr, however depending on the attributes set above, and in the module’s spec, you can more explicitly control the repr of module objects. If the module has a spec ($_{__spec__}$ ), the import machinery will try to generate a repr from it. If that fails or there is no spec, the import system will craft a default repr using whatever information is available on the module. It will try to use the$_{module.__name__}$ ,$_{module.__file__}$ , and$_{module.__loader__}$ as input into the repr, with defaults for whatever information is missing. Here are the exact rules used: Chapter 5. The import system 56 • If the module has no$_{__file__}$ but does have a$_{__loader__}$ that is not$_{None}$ , then the loader’s repr is used as part of the module’s repr. • Otherwise, just use the module’s$_{__name__}$ in the repr. • If the module has a$_{__file__}$ attribute, this is used as part of the module’s repr. • If the module has a$_{__spec__}$ attribute, the information in the spec is used to generate the repr. The “name”, “loader”, “origin”, and “has_location” attributes are consulted. 5.4.6 Module reprs 5.4.5 module.__path__ The Python Language Reference, Release 3.9.5 It is also appropriate to set$_{__cached__}$ when$_{__file__}$ is not set. However, that scenario is quite atypical. Ultimately, the loader is what makes use of$_{__file__}$ and/or$_{__cached__}$ . So if a loader can load from a cached module but otherwise does not load from a file, that atypical scenario may be appropriate. If __file__ is set, it may also be appropriate to set the __cached__ attribute which is the path to any compiled version of the code (e.g. byte-compiled file). The file does not need to exist to set this attribute; the path can simply point to where the compiled file would exist (see PEP 3147 ). __file__ is optional. If set, this attribute’s value must be a string. The import system may opt to leave __file__ unset if it has no semantic meaning (e.g. a module loaded from a database). Non-package modules should not have a __path__ attribute. If the module is a package (either regular or namespace), the module object’s __path__ attribute must be set. The value must be iterable, but may be empty if __path__ has no further significance. If __path__ is not empty, it must produce strings when iterated over. More details on the semantics of __path__ are given below . Changed in version 3.6:$_{__spec__.parent}$ is used as a fallback when$_{__package__}$ is not defined. New in version 3.4. __path__ __file__ __cached__