Вопрос-Ответ

Why is "import *" bad?

Почему "import *" плох?

Рекомендуется не использовать import * в Python.

Кто-нибудь, пожалуйста, может поделиться причиной этого, чтобы я мог избежать этого в следующий раз?

Переведено автоматически
Ответ 1

  • Потому что он помещает много материала в ваше пространство имен (может затенять какой-то другой объект из предыдущего импорта, и вы не будете знать об этом).


  • Потому что вы не знаете точно, что импортируется, и не можете легко найти, из какого модуля была импортирована определенная вещь (читаемость).


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


Ответ 2

Согласно дзену Python:


Явное лучше неявного.


... с этим, конечно, не поспоришь?

Ответ 3

Вы не передаете **locals() функциям, не так ли?

Поскольку в Python отсутствует оператор "include", и self параметр является явным, а правила определения области видимости довольно просты, обычно очень легко указать пальцем на переменную и сказать, откуда взялся этот объект - без чтения других модулей и без какой-либо IDE (которые в любом случае ограничены в плане самоанализа из-за того, что язык очень динамичный).

import * нарушает все это.

Кроме того, у него есть конкретная возможность скрывать ошибки.

import os, sys, foo, sqlalchemy, mystuff
from bar import *

Теперь, если модуль bar имеет какой-либо из атрибутов "os", "mystuff" и т.д. ..., Они будут переопределять явно импортированные и, возможно, указывать на совсем другие вещи. Определение __all__ в bar часто бывает разумным - это указывает, что будет неявно импортировано, - но все же трудно отследить, откуда берутся объекты, без чтения и синтаксического анализа модуля bar и отслеживания его импорта. Сеть import * - это первое, что я исправляю, когда становлюсь владельцем проекта.

Поймите меня правильно: если бы import * отсутствовал, я бы плакал, чтобы иметь его. Но его нужно использовать осторожно. Хороший вариант использования - предоставить фасадный интерфейс поверх другого модуля. Аналогично, использование операторов условного импорта или импорта внутри пространств имен функций / классов требует некоторой дисциплины.

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

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

Ответ 4

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

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

В модуле foo:

def myFunc():
print 1

В вашем коде:

from foo import *

def doThis():
myFunc() # Which myFunc is called?

def myFunc():
print 2
python