Хорошая или плохая практика в Python: импорт посреди файла

Некоторые опции:

  1. Генерируют Ваш CSS динамично, или на лету или поскольку Вы создаете свои таблицы стилей (я использую макросы Visual Studio, чтобы реализовать константы для шрифтов, чисел и цветов - и вычислить легкие/темные оттенки цветов). Эта тема была очень обсуждена в другом месте на этом сайте.

  2. , Если у Вас есть много стилей, которые 140 пкс шириной и Вы хотите иметь гибкость изменения того размера для всех тех стилей, Вы могли сделать это:

    div.FixedWidth {width:140px;}
    div.Style1 {whatever}
    div.Style2 {whatever}
    

и

    <div class="Style1 FixedWidth">...</div>
    <div class="Style2 FixedWidth">...</div>
57
задан CharlesB 25 February 2013 в 15:10
поделиться

9 ответов

PEP 8 авторитетно заявляет:

Импорт всегда помещается в начало файл сразу после любого модуля комментарии и строки документации, а также перед глобальными переменными и константами модуля.

PEP 8 должен быть основой любого «внутреннего» руководства по стилю, поскольку он суммирует то, что основная команда Python сочла наиболее эффективным стилем в целом (и с индивидуальным несогласием, конечно, как и на любом другом языке, но консенсус и BDFL соглашаются по PEP 8).

62
ответ дан 24 November 2019 в 19:26
поделиться

Подробное обсуждение этой темы в списке рассылки Python в 2001 году:

https://mail.python.org/pipermail/python-list/2001-July/071567 .html

18
ответ дан 24 November 2019 в 19:26
поделиться

Все остальные уже упоминали PEP, но также позаботьтесь о том, чтобы не имели операторы импорта в середине критического кода. По крайней мере, в Python 2.6 требуется еще несколько инструкций байт-кода, когда функция имеет оператор импорта.

>>> def f():
    from time import time
    print time()

>>> dis.dis(f)
  2           0 LOAD_CONST               1 (-1)
              3 LOAD_CONST               2 (('time',))
              6 IMPORT_NAME              0 (time)
              9 IMPORT_FROM              0 (time)
             12 STORE_FAST               0 (time)
             15 POP_TOP             

  3          16 LOAD_FAST                0 (time)
             19 CALL_FUNCTION            0
             22 PRINT_ITEM          
             23 PRINT_NEWLINE       
             24 LOAD_CONST               0 (None)
             27 RETURN_VALUE

>>> def g():
    print time()

>>> dis.dis(g)
  2           0 LOAD_GLOBAL              0 (time)
              3 CALL_FUNCTION            0
              6 PRINT_ITEM          
              7 PRINT_NEWLINE       
              8 LOAD_CONST               0 (None)
             11 RETURN_VALUE  
17
ответ дан 24 November 2019 в 19:26
поделиться

Если импортированный модуль используется нечасто и импорт является дорогостоящим, импорт посередине в порядке.

В противном случае, разумно ли последовать совету Алекса Мартелли.

11
ответ дан 24 November 2019 в 19:26
поделиться

Обычно это считается плохой практикой, но иногда это неизбежно (например, когда нужно избегать циклического импорта).

Пример того, когда это необходимо: я использую Waf для сборки всего нашего кода . Система разделена на инструменты, и каждый инструмент реализован в собственном модуле. Каждый инструментальный модуль может реализовать метод detect () для определения наличия предварительных условий. Пример одного из них может сделать следующее:

def detect(self):
    import foobar

Если это работает правильно, инструмент можно использовать. Позже в том же модуле может потребоваться модуль foobar , поэтому вам придется импортировать его снова в области видимости функции. Ясно, что если бы он был импортирован на уровне модуля, все полностью взорвалось бы.

8
ответ дан 24 November 2019 в 19:26
поделиться

Считается «хорошим тоном» группировать все импортированные данные вместе в начале файла.

Модули могут импортировать другие модули. Обычно, но не обязательно, помещать все операторы импорта в начало модуля (или скрипта, если на то пошло). Имена импортированных модулей помещаются в глобальную таблицу символов импортирующего модуля.

Отсюда: http://docs.python.org/tutorial/modules.html

7
ответ дан 24 November 2019 в 19:26
поделиться

PEP8 :

Импорт всегда помещается в начало файл сразу после любого модуля комментарии и строки документации, а также перед глобальными переменными и константами модуля.

Это неплохая практика - ограничивать импорт. Так что импорт применяется только к той функции, в которой вы его использовали.

Я думаю, что код будет более читабельным, хотя если бы импорт был сгруппирован вместе в верхней части блока или если вы хотите, чтобы он был глобально в верхней части файла .

2
ответ дан 24 November 2019 в 19:26
поделиться

Что ж, я думаю, что это хорошая практика - группировать весь импорт вместе в начале файла, так как каждый знает, где искать, если хочет узнать, какие библиотеки загружены

2
ответ дан 24 November 2019 в 19:26
поделиться

В 95% случаев вы должны помещать весь свой импорт в начало файла. Один из случаев, когда вы можете захотеть выполнить локальный импорт для функции, - это если вам нужно сделать это, чтобы избежать циклического импорта. Скажем, foo.py импортирует bar.py, а функция в bar.py должна что-то импортировать из foo.py. Если вы поместите весь свой импорт вверху, у вас могут возникнуть непредвиденные проблемы с импортом файлов, которые полагаются на информацию, которая еще не была скомпилирована. В этом случае наличие функции локального импорта может позволить вашему коду отложить импорт другого модуля до тех пор, пока его код не будет полностью скомпилирован и вы не вызовете соответствующую функцию.

Однако похоже, что ваш вариант использования больше о том, чтобы прояснить, откуда берется foo (). В этом случае я бы предпочел одно из двух:

Во-первых, а не

from prerequisite import foo

предварительное условие импорта напрямую, а позже назовите его prerequisite.foo. Повышенная многословность окупается за счет повышения прозрачности кода.

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

6
ответ дан 24 November 2019 в 19:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: