頭の悪い俺にもようやくimportがわかりかけてきたぞと。

実は、いままで俺は
importが何であるか真に理解してはいなかった

単に機械的に importが必要だから書いておこう、とか
なんかimport書いても思ったように動かずダメだから
よくわかんないけどfrom hoge import * にしてやれ、みたいな使い方であった。

そこで備忘録を兼ねて俺が理解したところを書いておこうと思う。つまりここに書かれている記述が正しいかどうかは保証しない。ただ、この時点ではテストコードにおいて正常に動作を確認した。
まず、

1) importは、#includeとかとはちょっと違う
C/C++のincludeってのはヘッダを参照するわけだ。
そんな感覚でimportすると、ちょっと違うことになる。
importってのは、「名前空間の読み込み」でもあるのだ。

たとえば、hoge.pyというPythonのスクリプトファイルがあった、としよう。
この中にはclass hogeが定義されている。
さて、他のスクリプト、ここではfoo.pyとしてみよう。
そのfoo.pyからそのclass hogeを再利用しようと思って

import hoge

とする。ここまでは普通だ。
そして、foo.pyにて

tmp = hoge()

とすると、これはエラーになる。そんなクラスは無い、と。
何故か。
import hogeで、名前空間hogeが自動生成されているからだ。
偶発的なクラスやグローバル変数や関数の名前の衝突の危険性を考えれば、実に納得の行く仕様である。
C++のincludeだったら、自分でnamespaceを書かねばならないところだ。

で、正解はどうなるか、といえば

tmp = hoge.hoge()

これでいいのである。
先日、pythonのクラスのスタティックメンバみたいな変数を代入のオーバーライドでは保護できないと喚いていた俺であるが、これを知れば一目瞭然。
あれは、クラスのスタティックメンバのようなものではなく、クラスの名前空間下のグローバル変数のようなものだったのだ。(って、C++のstaticもよく考えればそんなようなもんか…)

2) じゃあfrom ～ importって何よ？
実はまだよく判っていないのだが、俺の理解では、

名前空間を解除してimportする

と言うことだと思う。
上の例で言えば、hoge.pyをfoo.pyでimport hogeするのではなく

from hoge import *

としたとする。
すると、

tmp = hoge()

このコードが通るのである。
この結果からして、名前空間をfoo側のままでhogeをインポートした…としか俺には思えない。
となれば…fromはあまり使わないほうがいいようにも思えるな。