「インポート*」が悪いのはなぜですか？

import *Pythonでは使用しないことをお勧めします。

誰もがその理由を教えてくれますか？そうすれば次回はそれを避けることができますか？

• 名前空間に多くのものを配置するためです（以前のインポートから他のオブジェクトをシャドウする可能性があり、それについてはわかりません）。

• 何がインポートされたのか正確にわからず、特定のものがインポートされたモジュール（読みやすさ）を簡単に見つけることができないため。

• pyflakesコード内のエラーを静的に検出するようなクールなツールを使用できないからです。

禅のPythonによると：

明示的は暗黙的よりも優れています。

...確かにそれを議論することはできませんか？

**locals()関数にパスしないのですか？

Pythonには「include」ステートメントがなく、selfパラメータは明示的であり、スコープ規則は非常に単純であるため、通常、他のモジュールを読み取ったり、種類を指定したりせずに、変数を指で指して、そのオブジェクトがどこから来たかを伝えるのは非常に簡単です。 IDEの（これは、とにかくイントロスペクションの方法が制限されており、言語が非常に動的であるという事実によって）。

import *休憩すべてのこと。

また、バグを非表示にする具体的な可能性もあります。

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

これで、barモジュールに「os」、「mystuff」などの属性がある場合、それらは明示的にインポートされた属性をオーバーライドし、非常に異なるものを指す可能性があります。定義__all__暗黙的にインポートされるか、この状態- -バーにすることは賢明なことが多いですが、オブジェクトが読み込みとバーモジュールを解析し、次ずに、どこから来た、まだそれが追跡するのは難しいの輸入を。import *プロジェクトの所有権を取得するときに最初に修正するのは、ネットワークです。

私を誤解しないでください。もしimport *欠けていたら、私はそれを持っていると叫びます。ただし、慎重に使用する必要があります。良い使用例は、別のモジュール上にファサードインターフェイスを提供することです。同様に、条件付きインポートステートメント、または関数/クラスの名前空間内のインポートを使用するには、多少の規則が必要です。

中規模から大規模のプロジェクト、または複数の貢献者がいる小規模なプロジェクトでは、静的分析（少なくともpyflakesを実行するか、適切に構成されたpylintを実行する）の観点から、最小限の衛生が必要であり、以前にいくつかの種類のバグをキャッチする必要があります彼らが起こります。

もちろん、これはpythonなので、自由にルールを破って調査してください。ただし、10倍に成長する可能性のあるプロジェクトには注意してください。ソースコードに規律がない場合は問題になります。

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

一般に、*モジュールまたはパッケージからインポートすることは、読みにくいコードを引き起こすことが多いため、推奨されません。

fooというモジュールに次のコードがあるとします。

import ElementTree as etree

そして、あなた自身のモジュールであなたは持っています：

from lxml import etree
from foo import *

これで、デバッグが難しいモジュールにlxmlのetreeが含まれているように見えますが、実際にはElementTreeが含まれています。

これらはすべて良い答えです。新しい人々にPythonでのコード作成を教えるときに、import *は非常に難しいます。あなたや彼らがコードを書かなかったとしても、それはまだつまずきです。

私は子供（約8歳）に、Minecraftを操作するためにPythonでプログラミングすることを教えています。（Atomエディター）で動作し、REPL駆動の開発を（bpythonを介して）教えるのに役立つコーディング環境を彼らに提供したいと思います。Atomでは、ヒント/補完がbpythonと同じくらい効果的に機能することがわかりました。幸い、他の統計分析ツールとは異なり、Atomはにだまされませんimport *。

ただし、この例を見てみましょう... このラッパーではfrom local_module import *、これらのブロックのリストを含むモジュールを束にしています。名前空間の衝突のリスクを無視しましょう。そうfrom mcpi.block import *することで、これらの不明瞭なタイプのブロックのリスト全体を、利用可能なものを知るために調べなければならないものにします。代わりにを使用したfrom mcpi import block場合は、入力するwalls = block.とオートコンプリートリストがポップアップ表示されます。

ここで人々が述べた有効なポイントを理解しました。ただし、「スターのインポート」が必ずしも悪い習慣であるとは限らない可能性があるという意見があります。

• すべての定数が呼び出されるモジュールに行くようにコードを構造化したいとき const.py：
  • もしそうならimport const、すべての定数について、それをとして参照する必要がありますがconst.SOMETHING、これはおそらく最も便利な方法ではありません。
  • 私がそうするならfrom const import SOMETHING_A, SOMETHING_B ...、明らかにそれはあまりに冗長すぎて、構造化の目的を無効にします。
  • したがって、私はこの場合、a from const import *を行う方が良い選択だと感じます。

次の2つの理由から、これは非常に悪い習慣です。

1. コードの読みやすさ
2. 変数/関数などをオーバーライドするリスク

以下のためのポイント1：レッツは、この例を参照してください。

from module1 import *
from module2 import *
from module3 import *

a = b + c - d

ここでは、コードを見る上で、誰がどのモジュールからに関するアイデアを取得しないだろうb、cとd実際に属している。

逆に、あなたがそれを好きなら：

#                   v  v  will know that these are from module1
from module1 import b, c   # way 1
import module2             # way 2

a = b + c - module2.d
#            ^ will know it is from module2

それはあなたにとってはるかにきれいです、そしてあなたのチームに加わる新しい人はより良い考えを持つでしょう。

以下のためのポイント2：両方を言ってみましょうmodule1とmodule2として変数を持っていますb。私がする時：

from module1 import *
from module2 import *

print b  # will print the value from module2

ここからの値module1は失われます。でb宣言されていてもコードが機能しない理由をデバッグするのは難しくmodule1、コードが使用することを期待してコードを記述しましたmodule1.b

異なるモジュールに同じ変数があり、モジュール全体をインポートしたくない場合は、次のようにすることもできます。

from module1 import b as mod1b
from module2 import b as mod2b

テストとして、「A 1」と「B 1」をそれぞれ出力する2つの関数AとBを持つモジュールtest.pyを作成しました。test.pyをインポートした後：

import test

。。。2つの関数をtest.A（）とtest.B（）として実行できます。「test」は名前空間のモジュールとして表示されるため、test.pyを編集すると、次のように再ロードできます。

import importlib
importlib.reload(test)

しかし、私が次のことをした場合：

from test import *

名前空間には "test"への参照がないため、編集後に（私が知る限り）再読み込みする方法はありません。これは、対話型セッションの問題です。一方、次のいずれかです。

import test
import test as tt

名前空間にモジュール名として「テスト」または「tt」を（それぞれ）追加します。これにより、再ロードが可能になります。

私が行った場合：

from test import *

名前「A」と「B」は名前空間に関数として表示されます。test.pyを編集して上記のコマンドを繰り返すと、変更されたバージョンの関数がリロードされません。

そして、次のコマンドはエラーメッセージを引き出します。

importlib.reload(test)    # Error - name 'test' is not defined

「from module import *」でロードされたモジュールをリロードする方法を誰かが知っている場合は、投稿してください。それ以外の場合、これはフォームを回避するもう1つの理由です。

from module import *

ドキュメントで提案されているように、運用import *コードでは（ほとんど）使用しないでください。

モジュール*からインポートすることは悪いことですが、パッケージから*をインポートすることはさらに悪いことです。デフォルトでは、以前に読み込まれたパッケージのサブモジュールを含むfrom package import *、パッケージので定義されている名前をインポートします。__init__.pyimportステートメント。

ただし、パッケージの__init__.pyコードでという名前のリストが定義__all__されている場合from package import *は、が検出されたときにインポートする必要があるサブモジュール名のリストと見なされます。

次の例を考えてみます（に何も__all__定義されていないと仮定しますsound/effects/__init__.py）：

# anywhere in the code before import *
import sound.effects.echo
import sound.effects.surround

# in your module
from sound.effects import *

最後のステートメントは、echoおよびsurroundモジュールを現在のネームスペースにインポートします（以前の定義を上書きする可能性があります）。これらはステートメントの実行sound.effects時にパッケージで定義されているためimportです。