Что такое хорошие эмпирические правила для импорта Python?

Я обычно использовал бы import X на уровне модуля. Если Вам только нужен отдельный объект от модуля, используйте from X import Y.

Только использование import X as Y в случае, если Вы иначе сталкиваетесь со столкновением имени.

я только использую импорт на функциональном уровне для импорта материала, в котором я нуждаюсь, когда модуль используется в качестве основного модуля, как:

def main():
  import sys
  if len(sys.argv) > 1:
     pass

HTH

Позвольте мне просто вставить часть разговора в django-dev списке рассылки, запущенном Guido van Rossum:

[...], Например, это - часть руководств по стилю Google Python [1], что весь импорт должен импортировать модуль, не класс или функцию от того модуля. Существует путь больше классов и функций, чем существуют модули, таким образом вспоминая, куда конкретная вещь прибывает из, намного легче, если это снабжается префиксом имя модуля. Часто несколько модулей, оказывается, определяют вещи с тем же именем - таким образом, читатель кода не должен возвращаться к вершине файла для наблюдения, из которого модуля импортируется имя.

Источник: http://groups.google.com/group/django-developers/browse_thread/thread/78975372cdfb7d1a

1: http://code.google.com/p/soc/wiki/PythonStyleGuide#Module_and_package_imports

Не делайте этого:

from X import *

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

, Кроме которого, это - просто вопрос стиля.

from X import Y

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

from X import A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P

Вы получаете идею. Именно тогда импорт как

import X

становится полезным. Или это или если я ничего действительно не использую в X очень часто.

Другие покрыли большую часть земли здесь, но я просто хотел добавить один случай, где я буду использовать import X as Y (временно), когда я испытаю новую версию класса или модуля.

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

import xyz_new as xyz

Затем как только мы сокращаем по всей кодовой базе, мы просто заменили бы xyz модуль с xyz_new и возвратили бы весь импорт в

import xyz

Я обычно пытаюсь использовать постоянного клиента import modulename, если имя модуля не длинно, или используемое часто..

, Например, я сделал бы..

from BeautifulSoup import BeautifulStoneSoup as BSS

.. таким образом, я могу сделать soup = BSS(html) вместо BeautifulSoup.BeautifulStoneSoup(html)

Или..

from xmpp import XmppClientBase

.. вместо того, чтобы импортировать весь из xmpp, когда я только использую XmppClientBase

Используя import x as y, удобно, если Вы хотите импортировать или очень длинные имена методов или предотвратить избиение существующего импорта/переменной/класса/метода (что-то, чего необходимо стараться избегать полностью, но это не всегда возможно)

, Говорят, что я хочу выполнить основное () функция из другого сценария, но у меня уже есть основное () функция..

from my_other_module import main as other_module_main

.. не заменил бы мой main функция с my_other_module main

, О, одна вещь - не делает from x import * - это делает Ваш код очень трудно для понимания, поскольку Вы не можете легко видеть, куда метод прибыл из (from x import *; from y import *; my_func() - где my_func определен?)

Во всех случаях, Вы могли просто сделать import modulename и затем делаете modulename.subthing1.subthing2.method("test")...

Эти from x import y as z материал просто для удобства - используют его каждый раз, когда это сделает Ваш код легче читать или записать!

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

import gat

node = gat.Node()
child = node.children()

Иногда не возможно записать ему этот путь, или тогда Вы хотите спустить вниз вещи из библиотеки, которую Вы импортировали.

from gat import Node, SubNode

node = Node()
child = SubNode(node)

Иногда Вы делаете это для партии вещей, если Ваша строка импорта переполняет 80 столбцов, Это - хорошая идея сделать это:

from gat import (
    Node, SubNode, TopNode, SuperNode, CoolNode,
    PowerNode, UpNode
)

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

Теперь я говорю Вам, почему это - лучшее соглашение.

Python, возможно, отлично имел автоматический импорт, который посмотрит от основного импорта для значения, когда это не сможет быть найдено от глобального пространства имен. Но это не хорошая идея. Я объясняю вскоре почему. В стороне это являющийся более сложным для реализации, чем простой импорт, программисты так не думало бы о depedencies и нашло бы из того, куда Вы импортировали вещи, должен быть сделан некоторый другой путь, чем просто изучение импорта.

Потребность узнать depedencies является одной причиной, почему люди ненавидят "от... импорта *". Некоторые плохие примеры, где необходимо сделать это, существуют хотя, например, opengl - переносы.

, Таким образом, определения импорта на самом деле ценны как определение depedencies программы. Это - путь, как необходимо использовать их. От них можно быстро просто проверить, куда некоторая странная функция импортируется из.

Эти import X as Y полезно, если у Вас есть различные реализации того же модуля/класса.

С немного вложил try..import..except ImportError..import с, можно скрыть реализацию от кода. См. lxml etree пример импорта :

try:
  from lxml import etree
  print("running with lxml.etree")
except ImportError:
  try:
    # Python 2.5
    import xml.etree.cElementTree as etree
    print("running with cElementTree on Python 2.5+")
  except ImportError:
    try:
      # Python 2.5
      import xml.etree.ElementTree as etree
      print("running with ElementTree on Python 2.5+")
    except ImportError:
      try:
        # normal cElementTree install
        import cElementTree as etree
        print("running with cElementTree")
      except ImportError:
        try:
          # normal ElementTree install
          import elementtree.ElementTree as etree
          print("running with ElementTree")
        except ImportError:
          print("Failed to import ElementTree from any known place")

Я с Джейсоном в том, что не пользуюсь

from X import *

Но в моем случае (я не эксперт-программист, так что мой код не слишком хорошо соответствует стилю кодирования) я обычно делаю в своих программах файл со всеми константами, такими как версия программы, авторы, сообщения об ошибках и все такое, так что файл - это просто определения, тогда я делаю импорт

from const import *

Это экономит мне кучу времени. Но это единственный файл, который имеет такой импорт, и это потому, что все внутри этого файла - просто переменные декларации.

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