Это Python для импорта внутренних функций?

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

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

Еще один момент: я предпочитаю получать ImportError исключение перед запуском любого кода - в качестве проверки работоспособности, так что это еще одна причина для импорта вверху.

Я использую pyChecker для проверки неиспользуемых модулей.

Я нарушаю PEP 8 в двух случаях:

• Циклический импорт: модуль A импортирует модуль B, но что-то в модуле B нуждается в модуле A (хотя это часто является признаком того, что мне нужно реорганизовать модули, чтобы устранить циклическую зависимость)
• Вставка точки останова pdb: import pdb; pdb.set_trace() Это удобно, b / c Я не хочу ставить import pdb в верхней части каждого модуля, который я мог бы захотеть отладить, и легко не забыть удалить импорт, когда я удаляю точку останова.

За пределами этих двух случаев рекомендуется размещать все наверху. Это делает зависимости более понятными.

Вот четыре варианта использования импорта, которые мы используем

1. import (и from x import y и import x as y) вверху

2. Выбор для импорта. На вершине.

   import settings
   if setting.something:
       import this as foo
   else:
       import that as foo
   

3. Условный импорт. Используется с библиотеками JSON, XML и т. Д. На вершине.

   try:
       import this as foo
   except ImportError:
       import that as foo
   

4. Динамический импорт. Пока что у нас есть только один пример этого.

   import settings
   module_stuff = {}
   module= __import__( settings.some_module, module_stuff )
   x = module_stuff['x']
   

   Обратите внимание, что этот динамический импорт не вводит код, но вводит сложные структуры данных, написанные на Python. Это что-то вроде маринованного фрагмента данных, за исключением того, что мы собирали его вручную.

   Это также более или менее находится в верхней части модуля.

Вот что мы делаем, чтобы код был понятнее:

• Модули должны быть короткими.

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

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

Следует иметь в виду: ненужный импорт может вызвать проблемы с производительностью. Так что, если эта функция будет вызываться часто, вам лучше просто поместить импорт вверху. Конечно, это оптимизация, поэтому, если есть веские основания полагать, что импорт внутри функции более понятен, чем импорт в верхней части файла, это в большинстве случаев превосходит производительность.

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

Как правило, я делаю это, если есть импорт, который используется только в одной функции.

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

FWIW, бывают случаи, когда имеет смысл импортировать внутри функции. Например, если вы хотите установить язык в cx_Oracle, вам необходимо установить переменную среды NLS_LANG перед ее импортом. Таким образом, вы можете увидеть такой код:

import os

oracle = None

def InitializeOracle(lang):
    global oracle
    os.environ['NLS_LANG'] = lang
    import cx_Oracle
    oracle = cx_Oracle

Я уже нарушал это правило для модулей, которые проходят самотестирование. То есть они обычно используются только для поддержки, но я определяю для них основную, так что, если вы запустите их сами по себе, вы можете проверить их функциональность. В этом случае я иногда импортирую getopt и cmd только в main, потому что я хочу, чтобы кто-то, читающий код, понял, что эти модули не имеют ничего общего с нормальной работой модуля и включаются только для тестирования.

Исходя из вопроса о загрузке модуля дважды - Почему не оба?

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

Взгляните на альтернативный подход, который используется в sqlalchemy: внедрение зависимости:

@util.dependencies("sqlalchemy.orm.query")
def merge_result(query, *args):
    #...
    query.Query(...)

Обратите внимание, как импортированная библиотека объявляется в декораторе и передается в качестве аргумента функции !