Я всегда использовал этот метод:
from sys import argv
и использовать argv
только с argv . Но есть соглашение об использовании этого:
import sys
и используя argv sys.argv
Второй метод делает код самостоятельно документированным, и я (действительно) придерживаюсь его. Но причина, по которой я предпочитаю первый метод, заключается в том, что он быстрый, потому что мы импортируем только ту функцию, которая необходима, а не импортируем весь модуль (который содержит больше бесполезных функций, которые Python будет тратить впустую время, импортируя их). Обратите внимание, что мне нужен только argv, а все остальные функции из sys для меня бесполезны.
Итак, мои вопросы. Первый метод действительно делает скрипт быстрым? Какой метод является наиболее предпочтительным? Почему?
from … import …
синтаксиса в PythonОтветы:
Импорт модуль не тратит ничего ; модуль всегда полностью импортируется (в
sys.modules
отображение), поэтому вы не используете егоimport sys
илиfrom sys import argv
не делаете разногласий.Единственная разница между этими двумя утверждениями заключается в том, какое имя связано;
import sys
привязывает имяsys
к модулю (такsys
->sys.modules['sys']
), в то время какfrom sys import argv
связывает другое имяargv
, указывая прямо на атрибут, содержащийся внутри модуля (такargv
->sys.modules['sys'].argv
). Остальная частьsys
модуля все еще там, используете ли вы что-нибудь еще из модуля или нет.Также нет разницы в производительности между этими двумя подходами. Да,
sys.argv
должен искать две вещи; он должен искатьsys
в вашем глобальном пространстве имен (находит модуль), а затем искать атрибутargv
. И да, используя его,from sys import argv
вы можете пропустить поиск атрибута, поскольку у вас уже есть прямая ссылка на атрибут. Ноimport
оператор все еще должен выполнять эту работу, он ищет тот же атрибут при импорте, и вам нужно будет использовать егоargv
только один раз . Если бы вам пришлось использоватьargv
тысячи раз в цикле, это могло бы иметь значение, но в данном конкретном случае это действительно не так.Выбор между тем или другим должен основываться на стиле кодирования .
В большом модуле я бы обязательно использовал
import sys
; Документация по коду имеет значение, и использованиеsys.argv
где-то в большом модуле делает намного более понятным то, на что вы ссылаетесь, чемargv
когда-либо.Если единственное место, которое вы используете,
argv
находится в'__main__'
блоке для вызоваmain()
функции, во чтоfrom sys import argv
бы то ни стало используйте, если вы чувствуете себя счастливее по этому поводу:Я бы все еще использовал
import sys
там сам. При прочих равных условиях (и они, в точности, с точки зрения производительности и количества символов, использованных для его написания), для меня это просто на глаз.Если вы импортируете что - то другое , то, возможно, производительность вступит в игру. Но только если вы используете определенное имя в модуле много раз , например в критическом цикле. Но тогда создание локального имени (внутри функции) будет еще быстрее:
источник
from...import
позволяет делатьpackage.attribute
большеpackage.subpackage_or_module.attribute
, чем , что может быть полезно, если у вас есть логические или концептуальные группировки внутри пакета, но вы хотите сделать вещи немного более удобными для пользователей вашего пакета. (numpy
делает что-то подобное, я полагаю.)from django.core.management.base import BaseCommand
лучше, и все остальное (особенноimport django
) может привести к нечитаемому коду. Поэтому, хотя мне нравится этот ответ, я думаю, что есть некоторые библиотеки (и особенно некоторые фреймворки), в которых соглашение нарушает простой импорт. Как всегда, используйте свое суждение о том, что лучше в данной ситуации. Но ошибка на стороне явного (другими словами, я согласен по большей части).import ... as
чтобы найти пакет с другим именем:import package.subpackage_or_module as shortname
.from parent import sub
делает, по сути, то же самое.Есть две причины в пользу использования,
import module
а неfrom module import function
.Во-первых, это пространство имен. Импорт функции в глобальное пространство имен может привести к конфликту имен.
Второе не имеет отношения к стандартным модулям, но важно для ваших собственных модулей, особенно во время разработки. Это вариант для
reload()
модуля. Учти это:С другой стороны
Что касается скорости ...
Независимо от того, импортируете ли вы модуль или импортируете функцию из модуля, Python проанализирует весь модуль. В любом случае модуль импортируется. «Импорт функции» - это не что иное, как привязка функции к имени. На самом деле
import module
это меньше работы для переводчика, чемfrom module import func
.источник
Я использую
from import
s всякий раз, когда это улучшает читабельность. Например, я предпочитаю (точки с запятой здесь только для экономии места):вместо:
Последнее сложнее читать (и писать) для меня, потому что оно содержит так много избыточной информации. Также полезно заранее знать, какие части модуля я использую.
Я предпочитаю обычные
import
s, если я использую много коротких имен из модуля:Или, если имя настолько универсально, что не имеет смысла вне его пространства имен:
источник
На мой взгляд, использование регулярных
import
улучшает читабельность. При просмотре кода Python мне нравится видеть, откуда данная функция или класс происходят именно там, где она используется. Это спасает меня от прокрутки к началу модуля, чтобы получить эту информацию.Что касается длинных имен модулей, я просто использую
as
ключевое слово и даю им короткие псевдонимы:В качестве исключения я всегда использую
from module import something
обозначения, когда имею дело с__future__
модулем. Вы просто не можете сделать это по-другому, если хотите, чтобы все строки были по умолчанию в Unicode в Python 2, напримеристочник
Хотя
import sys
иfrom sys import agrv
как импортировать весьsys
модуль, последний использует имя связывания так толькоargv
модуль доступен для остальной части кода.Для некоторых это предпочтительный стиль, поскольку он делает доступной только функцию, которую вы явно указали.
Это, однако, вводит потенциальные конфликты имен. Что если у вас есть другой модуль с именем
argv
? Обратите внимание, что вы также можете явно импортировать функцию и переименовать сfrom sys import argv as sys_argv
помощью соглашения, которое соответствует явному импорту и с меньшей вероятностью приведет к коллизиям пространства имен.источник
if sys_argv:
лучше чемif sys.argv:
? Я знаю, что означает второе утверждение, я понятия не имею, что означает первая форма, не возвращаясь к странному импорту.Я недавно задал этот вопрос себе. Я рассчитал разные методы.
библиотека запросов
красивая библиотека
библиотека JSON
библиотека sys
Мне кажется, что есть небольшая разница в производительности.
источник
import module
сfrom module import name
правильно добавить , что поиск имени вimport module
случае. Например, добавьте строкуsys.argv
вar
тест и т. Д. Разница все равно будет существовать, потому что проделанная работа немного отличается, поскольку генерируется другой байт-код и выполняются разные пути кода.import sys
использованиемsys.argv
тысяч раз в цикле по сравнениюfrom sys import argv
с использованием простоargv
. Но ты не. Для вещей, которые вы делаете только один раз на глобальном уровне вашего модуля, вы действительно должны оптимизировать для удобства чтения, а не микроскопических различий во времени.Просмотр опубликованных фрагментов кода, импорт целых модулей и ссылки на
module.function
них в значительной степени являются стандартом, по крайней мере для стандартных модулей. Единственное исключение, кажется,datetime
так что вы можете сказать,
datetime.now()
а неdatetime.datetime.now()
.Если вы беспокоитесь о производительности, вы всегда можете сказать (например)
а затем выполните критический для производительности код, поскольку поиск модуля уже выполнен. Однако, хотя это будет работать с функциями / методами, большинство IDE будут сбиты с толку и не будут (например) отображать исходную ссылку / подпись для функции, когда она назначается переменной.
источник
Я просто хочу добавить, что если вы делаете что-то вроде
(или любая другая встроенная библиотека, такая как
sys
илиposix
), затемsin
будет включена в документацию для вашего модуля (то есть, когда вы делаете>>> help(mymodule)
или$ pydoc3 mymodule
. Чтобы избежать этого, импортируйте, используя:PS: встроенная библиотека - это библиотека, которая скомпилирована из кода C и включена в Python.
argparse
,os
Аio
не встроенные в пакетахисточник