[Python知识库] 【代码规范化】如何正确的使用 Python Import

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> Python知识库 -> 【代码规范化】如何正确的使用 Python Import -> 正文阅读

[Python知识库]【代码规范化】如何正确的使用 Python Import

`from ... import` vs. `import`

Always avoid wildcard imports like such:

from my_module import *  # don't use this

Instead, use regular import like:

import my_module  # use this

Why?

using wildcard import will pollute namespaces
Using wildcard import will not import names with a leading underscore (unless the module defines an __all__ list)
PEP8 recommend using regular import

What does `init.py` do?

__init__.py is used to specify a package, when import is trying to find the modules,
But it is not required: meaning a package without __init__.py,
The system can still find the modules after configuring appropriate PYTHONPATH using
sys.path.append.
__init__.py is executed after importing the package, I’ve seen
sub-directory being imported by appending as environment variable within __init__.py

Example:

so instead of using import project.foo.bar for the following structure:

project/
    __init__.py
    foo/
        __init__.py
        bar/
            b.py

inside the __init__.py, we could do a sys.path.append(PATH_TO_BAR)

so with this file structure, you can just do import project

they could even add the import statement for you in the __init__.py, although it is not transparent.

project/
    __init__.py
    foo/
        bar/
            b.py

Note: Whatever gets appended last overrides the previous
env variable, so import to the same name module will find the latest append

Dot notation (`.`) in Import

parent/
    __init__.py
    file.py
    one/
        __init__.py
        anotherfile.py
    two/
        __init__.py
    three/
        __init__.py

Each dot in your import will refer to something inside the package, could be another package
or a module. But it can’t be a class.

Import python modules could look like:
import parent.file or import parent.one.anotherfile

From … import classes or functions look like this:
from parent.file import class
which gives you direct access to the class namespace, but not the example above.

Import Order

Based on PEP8, imports should be grouped by the following order:

Standard library import
Related third-party import
Local application/library specific import

What is Standard Library Imports?

Standard library are installed automatically by Python installer, full documentation link
is here: https://docs.python.org/3/library/

What is the order after grouping?

There is no specific rules, but based on common preferences, use alphabetical order, with
import first and from … import after

import abc
import def
import x
from g import gg
from x import xx

Intra-Package

In a structure like this, how would you do import from another directory?
say from module-x.py import module-a

top-package/
    __init__.py
    sub-package-a/
        __init__.py
        module-x.py
        module-y.py
    sub-package-b/
        __init__.py
        module-a.py
        module-b.py

Here’s some examples doing relative imports in module-x

import module-y
from . import module-y
from .module-y import classA
from .. import sub-package-b
from ..subpackage-b import module-a
from ..subpackage-b.module-a import classB

Import an import

It is a common practice in C# to use import module or static class to stores all the global variables
used for settings, or even all the modules. In Python it would be something like:
constant.py

import module_a
import module_b
import module_c

GLOBAL_VAR_MAX = 50
GLOBAL_VAR_MIN = 10
GLOBAL_VAR_TIMEOUT = 2000

GLOBAL_NAME = r'random name'

# or even
class Constant(object):
    gravity = 9.8
    is_true = True

With this setup, all the module in the same project would just import the constant module and have access to
all the imports and variable. I thought this was a neat way to make code cleaner by getting rid of all the duplicated imports
that might happen.

there are also some voices against it:

based on the style guide: Constants are usually defined on a module level
also, suggestions have mentioned to refrain from using class as it could be instantiated which makes no sense.
unless there’s a valid reason for all those modules to be collected under a common name. If not, then they should
be kept separately. This is due to documentation, as other people open your file, they don’t get information on
what is getting imported (what is needed)

Same module import multiple times

So if multiple files are importing the same module separately, does python optimize the import?

Yes, python modules are considered as singletons, no matter how many times you import them they get initialized only once.
unless reload is being called