所以这只是一个简单的问题。 在python中导入模块时,这有什么区别:
from module import a, b, c, d
还有这个
from module import a
from module import b
from module import c
from module import d
对我来说,压缩代码并使用第一个示例总是有意义的,但是我已经看到一些代码示例出现在第二个示例中。 到底有什么不同,还是都在程序员的偏好上?
一点区别都没有。 它们的功能完全一样。
然而,从文体的角度来看,一个可能比另一个更可取。 关于这一点,用于导入的PEP-8规定,您应该将从module import name1,name2
压缩到单行,并将import module1
保留在多行:
Yes: import os
import sys
No: import sys, os
Ok: from subprocess import Popen, PIPE
针对@Teewuane的评论(在此重复,以防评论被删除):
@inspectorg4dget如果您必须从一个模块中导入多个函数,且最终使行长度超过80个字符,该怎么办? 我知道80字符的事情是“当它使代码更易读时”,但我仍然想知道是否有一个更整洁的方法来做到这一点。 而且我不想从foo导入*即使我基本上导入了所有东西。
这里的问题是,执行以下操作可能会超过80个字符的限制:
from module import func1, func2, func3, func4, func5
对此,我有两种回应(我不认为PEP8对此过于明确):
将其分解为两个导入:
from module import func1, func2, func3
from module import func4, func5
这样做的缺点是,如果从代码库中移除module
或以其他方式进行重构,那么将需要删除两个导入行。 这可能会很痛苦
分线:
为了减轻上述担忧,可能更明智的做法是
from module import func1, func2, func3, \
func4, func5
如果第二行不与第一行一起删除,同时仍保留单数import语句,这将导致错误
为了补充Inspectorg4dGet的回答中提出的一些问题,当文件夹结构开始深度嵌套或模块名称不明确时,还可以使用元组执行多行导入。
from some.module.submodule.that_has_long_names import (
first_item,
second_item,
more_imported_items_with_really_enormously_long_names_that_might_be_too_descriptive,
that_would_certainly_not_fit,
on_one_line,
)
虽然我不是这种风格的粉丝,但这也是可行的:
from module import (a_ton, of, modules, that_seem, to_keep, needing,
to_be, added, to_the_list, of_required_items)
我建议不要盲目地遵循PEP-8。 当你有大约一半屏幕价值的导入,事情开始变得不舒服,然后PEP-8与PEP-20的可读性准则相冲突。
我的偏好是,
上面给了您很好的平衡,因为读者仍然可以快速浏览依赖项,同时实现合理的紧凑性。
例如,
我的首选项
# one line per package
import os, json, time, sys, math
import numpy as np
import torch, torch.nn as nn, torch.autograd, torch.nn.functional as F
from torchvision models, transforms
PEP-8命令
# one line per module or from ... import statement
import os
import json
import time
import sys
import math
import numpy as np
import torch
from torch import nn as nn, autograd, nn.functional as F
from torchvision import models, transforms