Есть ли рекомендуемый формат для многострочного импорта?

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)

Есть ли рекомендуемый формат или более элегантный способ для этого утверждения?

python python-2.7 pep8

— Мануэль Альварес
источник

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

— Motin

16

Ваши примеры, похоже, происходят из PEP 328 . Здесь круглые скобки предложены именно для этой задачи, так что, наверное, я бы выбрал именно эту.

— Торстен Кранц
источник

4

Я бы выбрал обозначение скобок из 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,
)

— Макс Малыш
источник

Нет новых строк, добавленных после / перед круглой скобкой в 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 это нормально, поскольку вы импортируете только виджеты; это даже указано в справочнике по библиотеке . И если вы укажете импорт первым, вы должны быть особенно защищены от любых конфликтов.

— poke

1

Для справки, проблема from X import *даже для пакетов, которые используются __all__правильно, заключается в том, что статические анализаторы кода, например, pyflakesне могут обнаруживать неопределенные имена, если они есть, import *поскольку они должны предполагать, что любые неопределенные имена могут быть импортированы пакетом *.

— RubenLaguna