问题:有多行导入的推荐格式吗?

我已经阅读了在python中编码多行导入的三种方法

带斜杠:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text, \
    LEFT, DISABLED, NORMAL, RIDGE, END

复制语句:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END

带括号:

from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

此语句是否有推荐的格式或更简洁的方法?

I have read there are three ways for coding multi-line imports in python

With slashes:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text, \
    LEFT, DISABLED, NORMAL, RIDGE, END

Duplicating senteces:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END

With parenthesis:

from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

Is there a recomended format or a more elegant way for this statements?


回答 0

就个人而言,导入多个组件并按字母顺序对它们进行括号处理。像这样:

from Tkinter import (
    Button,
    Canvas,
    DISABLED,
    END,
    Entry,
    Frame,
    LEFT,
    NORMAL,
    RIDGE,
    Text,
    Tk,
)

这具有额外的优势,即可以轻松查看每个提交或PR中已添加/删除了哪些组件。

总的来说,尽管这是个人喜好,但我建议您选择最适合自己的方式。

Personally I go with parentheses when importing more than one component and sort them alphabetically. Like so:

from Tkinter import (
    Button,
    Canvas,
    DISABLED,
    END,
    Entry,
    Frame,
    LEFT,
    NORMAL,
    RIDGE,
    Text,
    Tk,
)

This has the added advantage of easily seeing what components have been added / removed in each commit or PR.

Overall though it’s a personal preference and I would advise you to go with whatever looks best to you.


回答 1

您的示例似乎源于PEP 328。在那里,正是针对这个问题提出了括号符号,所以我可能会选择这个。

Your examples seem to stem from PEP 328. There, the parenthesis-notation is proposed for exactly this problem, so probably I’d choose this one.


回答 2

我将使用PEP328的括号符号,并在括号之前和之后添加换行符:

from Tkinter import (
    Tk, Frame, Button, Entry, Canvas, Text, 
    LEFT, DISABLED, NORMAL, RIDGE, END
)

这是Django使用的格式:

from django.test.client import Client, RequestFactory
from django.test.testcases import (
    LiveServerTestCase, SimpleTestCase, TestCase, TransactionTestCase,
    skipIfDBFeature, skipUnlessAnyDBFeature, skipUnlessDBFeature,
)
from django.test.utils import (
    ignore_warnings, modify_settings, override_settings,
    override_system_checks, tag,
)

I would go with the parenthesis notation from the PEP328 with newlines added before and after parentheses:

from Tkinter import (
    Tk, Frame, Button, Entry, Canvas, Text, 
    LEFT, DISABLED, NORMAL, RIDGE, END
)

This is the format which Django uses:

from django.test.client import Client, RequestFactory
from django.test.testcases import (
    LiveServerTestCase, SimpleTestCase, TestCase, TransactionTestCase,
    skipIfDBFeature, skipUnlessAnyDBFeature, skipUnlessDBFeature,
)
from django.test.utils import (
    ignore_warnings, modify_settings, override_settings,
    override_system_checks, tag,
)

回答 3

通常对于Tkinter,只使用from Tkinter import *模块就可以了,因为该模块只会导出明显是小部件的名称。

PEP 8没有列出这种情况下的任何约定,因此我想您应该决定什么是最佳选择。一切都与可读性有关,因此请选择任何可以使您清楚地表明要从单个模块导入内容的东西。

由于在您的范围内提供了所有这些名称,因此我个人认为选项2最清晰,因为您可以看到最佳的导入名称。然后,您甚至可以将其拆分成更多的部分,以将彼此属于的那些名称组合在一起。在您的示例中,我可能将和分开放置Tk,因为它们将小部件分组在一起,而将和分开放置则是它们在视图中较小的组件。FrameCanvasButtonText

Usually with Tkinter, it is okay to just use from Tkinter import * as the module will only export names that are clearly widgets.

PEP 8 does not list any conventions for such a case, so I guess it is up to you to decide what is the best option. It is all about readability, so choose whatever makes it clear that you are importing stuff from a single module.

As all those names are made available in your scope, I personally think that options 2 is the most clearest as you can see the imported names the best. You then could even split it up more to maybe group those names together that belong with each other. In your example I might put Tk, Frame and Canvas separately as they group widgets together, while having Button and Text separately as they are smaller components in a view.


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。