'из X импортировать' против 'импортировать X; X.a» - PullRequest
9 голосов
/ 09 октября 2008

Я видел, как некоторые программисты на Python довольно последовательно используют следующий стиль (назовем его style 1):

import some_module
# Use some_module.some_identifier in various places.

Для поддержки этого стиля вы можете указать «явное лучше, чем неявное» максима. Я видел, как другие программисты использовали этот стиль (стиль 2):

from some_module import some_identifier
# Use some_identifier in various places.

Основным преимуществом, которое я вижу в стиле 2, является удобство сопровождения - особенно с идеалами Утиная печать , которые я могу захотеть поменять some_module на some_other_module. Я также чувствую очки выигрыша стиля 2 с максимой "читаемость" . Хотя я склонен не соглашаться с этим, всегда можно утверждать, что поиск и замена - такой же хороший вариант при использовании первого стиля.

Приложение: Было отмечено, что вы можете использовать as для решения вопроса о переключении с some_module на some_other_module в стиле 1. Я забыл упомянуть, что также принято решение о реализации some_identifier в вашем текущем модуле, что делает создание эквивалентного some_module контейнера немного неловким.

Ответы [ 9 ]

5 голосов
/ 09 октября 2008

При наличии следующего синтаксиса:

import some_other_module as some_module

аргумент ремонтопригодности стиля 2 больше не актуален.

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

5 голосов
/ 09 октября 2008

Существуют варианты использования в обоих случаях, поэтому я не думаю, что это проблема или. Я хотел бы рассмотреть возможность использования из модуля import x,y,z, когда:

  • Есть довольно небольшое количество вещей для импорта

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

  • Имена не конфликтуют. Похоже на вышесказанное, но важнее. Никогда не делать что-то вроде:

     from os import open
    

import module [as renamed_module] имеет то преимущество, что дает немного больше контекста о том, что вызывается, когда вы его используете. Недостатком является то, что это немного более загромождено, когда модуль на самом деле не дает больше информации, и немного менее производительно (2 поиска вместо 1).

Однако он также имеет преимущества при тестировании (например, замена os.open на фиктивный объект, без необходимости менять каждый модуль) и должен использоваться при использовании изменяемых модулей, например,

import config
config.dburl = 'sqlite:///test.db'

Если сомневаетесь, я всегда буду придерживаться стиля import module.

2 голосов
/ 09 октября 2008

Я предпочитаю import X, а затем используйте X.a как можно больше.

Мое исключение сосредоточено на глубоко вложенных модулях в такой большой среде, как Django. Их имена модулей имеют тенденцию становиться длинными, и все их примеры говорят from django.conf import settings, чтобы сохранить вас, набрав django.conf.settings.DEBUG везде.

Если имя модуля глубоко вложено, исключение составляет from X.Y.Z import a.

2 голосов
/ 09 октября 2008

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

import some_module as sm
x = sm.whatever

Если мне нужна только одна или две вещи:

from some_module import whatever
x = whatever

Это предполагает, что мне не нужно whatever от some_other_module, конечно.

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

1 голос
/ 09 октября 2008

Я считаю, что запись

from some_module import some_symbol

работает лучше всего в большинстве случаев. Также, в случае столкновения имени для символа, вы можете использовать:

from some_module import some_symbol as other_symbol

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

import  module [as other_module]

Только в двух случаях:

  1. Я использую слишком много функций / объектов модуля, чтобы импортировать их все
  2. Модуль определяет некоторый символ, который может измениться во время выполнения
0 голосов
/ 17 июня 2011
0 голосов
/ 09 октября 2008

Я склонен использовать только несколько членов каждого модуля, поэтому есть много

from john import cleese
from terry import jones, gilliam

в моем коде. Я импортирую целые модули (такие как os или wx), если я ожидаю использовать большую часть модуля, а имя модуля короткое. Я также импортирую целые модули, если есть конфликт имен или я хочу напомнить читателю, с чем связана эта функция.

import michael
import sarah

import wave

gov_speech = wave.open(sarah.palin.speechfile)
parrot_sketch = wave.open(michael.palin.justresting)

(я мог бы использовать from wave import open as wave_open, но я полагаю, что wave.open будет более знакомым для читателя.

0 голосов
/ 09 октября 2008

Лично я стараюсь не слишком возиться с моим пространством имен, поэтому в большинстве случаев я просто делаю

import module  

или модуль импорта как мод

Реальная разница только тогда, когда у меня есть модуль с одним классом, который часто используется. Если бы я добавил sublclassed тип list для добавления функциональности, я бы использовал

from SuperImprovedListOverloadedWithFeatures import NewLIst
nl = NewList()

и т.д.

0 голосов
/ 09 октября 2008

Я верю в новые версии Python (2.5+? Должны проверить мои факты ...), вы даже можете сделать:

import some_other_module as some_module

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

Я думаю, что это в целом соответствует тому, насколько сильно вы хотите загромождать пространство имен. Вы просто будете использовать одно или два имени в модуле? Или все они (from x import * не всегда плохо, просто в целом)?

...