Является ли "импорт модуля" лучшим стилем кодирования, чем "из функции импорта модуля"?

классический текст об этом, как это часто бывает, от Фредрика Лунда, эффбота. Его совет:всегда используйте import - кроме случаев, когда вы не должны.

другими словами, будьте благоразумны. Лично я считаю, что все, что несколько модулей глубоко, как правило, импортируется через from x.y.z import a - основным примером являются модели Django. Но как и все остальное, это вопрос стиля, и вы должны иметь последовательный - особенно с модулями, такими как datetime, где и модуль и класс, который он содержит, называется то же самое. Вам нужно написать datetime.datetime.now() или просто datetime.now()? (В моем коде всегда первое.)

пункты 1 и 2 в вашем списке вопросов, кажется, та же проблема. Динамическая природа Python означает, что довольно просто заменить элемент в пространстве имен модуля независимо от того, какой из методов вы используете. Трудность возникает, если одна функция в модуле ссылается на другую, которую вы хотите высмеять. В этом случае импортируйте модуль, а не функции означает, что вы можете сделать module.function_to_replace = myreplacementfunc и все работает прозрачно - но это так же легко сделать через FPIM, как и через IM.

Я также не понимаю, как пункт 3 имеет какое-либо отношение к чему-либо. Я думаю, что Ваш пункт 4, однако основан на небольшое недоразумение. Ни один из методов, которые вы даете, не будет "загрязнять ваше пространство имен". Что тут это from module import *, где вы понятия не имеете, что вы импортируете, и поэтому функции могут появляться в вашем коде без каких-либо подсказка дана читателю откуда они взялись. Это ужасно, и его следует избегать любой ценой.

как Алекс Мартелли, я люблю использовать as при импорте функции.

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

from random import seed as r_seed
from random import random as r_random

r_seed короче, чем random.seed но несколько сохраняет границы модуля. Кто-то случайно глядя на ваш код может видеть r_seed() и r_random() и есть шанс понять, что они связаны.

конечно, вы всегда можете просто делать:

import random as r

и затем использовать r.random() и r.seed(), что может быть идеальным компромиссом для этого случая. Я использую трюк с префиксом только при импорте одной или двух функций из модуля. Когда я хочу использовать много функций из одного модуля, я импортирую модуль, возможно, с as чтобы сократить название.

отличные ответы здесь (я их всех поддержал), и вот мои мысли по этому поводу:

во-первых, обращаясь к каждой из ваших пуль:

(предположительно) плюсы FMIF:

• краткость кода: более короткие имена функций помогают придерживаться 80 столбцов в строке.

возможно, но имена модулей обычно достаточно короткие, поэтому это не актуально. Конечно, есть datetime, но и os, re,sys и т. д. И Python имеет свободные разрывы строк внутри { [ (. А для вложенных модулей всегда есть as как в IM, так и в FPIM

• читаемость: chisquare(...) выглядит более читаемым, чем составляющей.статистика.статистика.chisquare(...).

категорически не согласен. При чтении иностранного кода (или моего собственного кода через несколько месяцев) трудно понять, откуда берется каждая функция. Квалифицированные имена спасают меня от перехода туда и обратно из строки 2345 в заголовок объявления модуля. И это также дает вам контекст:"chisquare? Что это такое? О, это от scypy? Хорошо, некоторые математические вещи, то". И, еще раз, вы всегда можете сократить scipy.stats.stats as scypyst. scypyst.chisquare(...) достаточно короткий со всеми преимуществами квалифицированного имени.

import os.path as osp еще один хороший пример, учитывая, что очень часто цепочка 3 или более его функций вместе в одном вызове: join (expanduser (), basename (splitext())) так далее.

• простота перенаправления: однострочное переопределение функции из altmodule вместо модуля.

как часто вы хотите переопределить одну функцию, а не весь модуль? Границы модуля и координация функций должны быть сохранены, и Алекс уже объяснил это очень подробно. Для большинства (всех?) реальные сценарии, если alt_module.x является жизнеспособной заменой для module.x, тогда наверное alt_module сам по себе является каплей Альтернатива для module, так как им и ФПИМ один-вкладыши FMIF как, если вы используете as.

• я понимаю, что FPIM каким-то образом сводит на нет первые две проблемы...

на самом деле as это тот, который смягчает первые 2 проблемы (и 3-й), а не FPIM. Вы можете использовать IM для этого тоже:import some.long.package.path.x as x для того же результата, что и FPIM.

---

таким образом, ни один из вышеперечисленных не является настоящим плюсом FMIF. И причины Я предпочитаю IM / FPIM являются:

для простоты и согласованности, когда я импортирую что-то, либо IM, либо FPIM, я всегда импортирую модуль, а не объект из модуля. Помните, что FMIF можно (ab-)использовать для импорта функций, классов, переменных или даже других модулей! Подумайте о беспорядке from somemodule import sys, somevar, os, SomeClass, datetime, someFunc.

кроме того, если вы хотите больше, чем один объект из модуля, FMIF будет загрязнять ваше пространство имен больше, чем IM или FPIM, который будет использовать одно имя независимо от того, сколько объектов вы хотите использовать. И такие объекты будут иметь квалификации имя, которое является pro, а не con: как я уже сказал в выпуске 2, IMHO a it улучшает читабельности.

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

Я согласен с MestreLion больше всего здесь (и так upvote).

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

код пишется один раз и читается много раз, и поэтому читаемость и ремонтопригодность превосходит простоту ввода.

в аналогичном ключе, как правило, код не пишется в интересах кодер, но в интересах другой сущности.

ваш код должен быть читаем для тех, кто знает python лучше, чем вы, но не знаком с кодом.

импорт полного пути также может лучше помочь IDE указать вам на правильный источник функции или объекта, на который вы смотрите.

по всем этим причинам и причинам, отмеченным MestreLion, я заключаю, что лучше всего импортировать и использовать полный путь.