Почему “импорт *” плохо?

Согласно Дзен Python :

Явное лучше, чем неявное.

... не могу ли с этим поспорить?

Предположим, у вас есть следующий код в модуле с именем foo:

import ElementTree as etree

, а затем в вашем собственном модуле:

from lxml import etree
from foo import *

Теперь у вас есть трудный для отладки модуль, который выглядит как он В нем есть lxml etree, но на самом деле вместо него есть ElementTree.

Можно делать from ... import * в интерактивной сессии.

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

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

В модуле foo:

def myFunc():
    print 1

В вашем коде:

from foo import *

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

def myFunc():
    print 2

http://docs.python.org/tutorial/modules.html

Обратите внимание, что в целом практика импорта * из модуля или пакета не одобряется, поскольку это часто приводит к плохо читаемому коду.

Вы же не передаете **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 - не стесняйтесь нарушать правила, и исследовать - но опасайтесь проектов, которые могут вырасти в десять раз, если исходный код не соответствует дисциплине, это будет проблемой.