Чи є рекомендований формат для багаторядкового імпорту?


114

Я читав, що існує три способи кодування багаторядкового імпорту в 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)

Чи є рекомендований формат чи більш елегантний спосіб для цих тверджень?


3
з такою кількістю імпорту, чому б не просто from Tkinter import *?
Inbar Rose

2
Це приклад. Це справжнє твердження, from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ WebEmbeddedFieldале не хочу імпортувати всі решта вбудованих полів у data.forms
Мануель Альварес

19
Багато причин. Наприклад, ви можете перезаписати багато змінних, про які ви не знаєте. Чи знаєте ви всі імена, імпортовані компанією from Tkinter import *? Я не. І IDE не дізнаються, чи є ці імена (можливо), тому вони не в змозі сказати, чи ввели ви невірне ім’я.
Торстен Кранц

2
@InbarRose Це поганий прийом, дивіться на stackoverflow.com/questions/3615125/…
Юваль Прус

Відповіді:


161

Особисто я йду з дужками, коли імпортують більше одного компонента і сортую їх за алфавітом. Так:

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

Це має додаткову перевагу в тому, щоб легко побачити, які компоненти були додані / видалені в кожному комісіоні чи PR.

Взагалі, хоча це особисті переваги, і я б радив вам піти з тим, що вам найбільше подобається.


3
Я думаю, що важливим є бути послідовним (принаймні, в рамках певного проекту). Це полегшить те, хто читає код, без особливих труднощів знайти те, що імпортується.
Blckknght

1
isort може використовуватися для автоматичного форматування імпорту кілька рядків в різних стилях, см github.com/timothycrosley/isort#multi-line-output-modes
Мотін

16

Ваші приклади, схоже, випливають з PEP 328 . Там дужки-позначення пропонуються саме для цієї проблеми, тому, ймовірно, я б обрав цю.


4

Я б пішов з позначеннями в дужках з PEP328 з новими рядками, доданими до та після дужок:

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

Це формат, який використовує Джанго :

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,
)

Не додано нових рядків після / перед дужки в PEP 328?
Гандальф Сакс

@GandalfSaxe PEP 328 стосувався семантики (додавання нової функції до мови), а не про форматування.
Макс Малиш

Я не зовсім розумію тоді. Ви цитуєте PEP 328 як дужки для багаторядкового імпорту, але їх немає? "Я б пішов із позначеннями дужок із PEP328 з новими рядками, доданими до та після дужок:"
Гендальф Сакс

PEP 328 додав позначення дужок до мови. Дужки нотація є можливість імпортувати кілька модулів , як це: from foo import (bar, baz). PEP 328 нічого не говорить про форматування.
Макс Малиш

Ну гаразд, я бачу, що ти маєш на увазі :)
Гендальф Сакс

-4

Зазвичай з Tkinter добре використовувати просто, from Tkinter import *оскільки модуль експортує лише імена, які є чітко віджетами.

PEP 8 не перелічує жодних конвенцій для такого випадку, тому я думаю, що саме ви вирішите, який варіант є найкращим. Вся справа в читанні, тому вибирайте все, що дає зрозуміти, що ви імпортуєте речі з одного модуля.

Оскільки всі ці імена доступні у вашому обсязі, я особисто вважаю, що варіанти 2 є найбільш зрозумілими, оскільки ви можете імпортувати імена найкраще. Тоді ви могли б навіть розділити його більше, щоб, можливо, згрупувати ті імена разом, які належать один одному. У вашому прикладі я міг би помістити Tk, Frameі Canvasокремо , як вони групуються віджети разом, маючи при цьому Buttonі по Textокремо , оскільки вони більш дрібні компоненти в поданні.


11
Ніколи не гаразд використовувати X імпорт *
Толо Палмер

1
@ToloPalmer Як правило, це правда, але для Tkinter це нормально, оскільки ви імпортуєте лише віджети; він навіть перерахований таким чином у довідці про бібліотеку . І якщо ви імпортуєте список як перший, ви повинні бути особливо безпечними від будь-яких конфліктів.
ткнути

1
Для довідки, проблема from X import *навіть для пакетів, які використовують __all__належним чином, полягає в тому, що аналізатори статичного коду, як-от, pyflakesне можуть виявити невизначені імена, якщо такі є, import *оскільки вони повинні вважати, що будь-які невизначені імена, можливо, були імпортовані *.
RubenLaguna
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.