同じ名前空間の中でファイル分割したい

Question

ソース管理のため、名前空間とファイル構成の両面でプロジェクトの階層化をしたいと考えています。

ファイル構成：

hogepackage
  +- __init_.py
  +- foo.py
  +- bar.py

実現したい名前空間とクラスの構成：

namespace hogepackage
  +- <init module>
  +- class Foo
  +- class Bar

しかし、Pythonではパッケージ（フォルダ）とモジュール（__init__以外のファイル）がそれぞれ名前空間の階層となるので、ファイル構成をそのまま適用すると以下のように余計な名前空間ができてしまいます。

namespace hogepackage
  +- <init module>
  +- namespace foo
  |    +- class Foo
  +- namespace bar
       +- class Bar

一般には__init__.pyの中でクラスをインポートすることで、利用側ではあたかもパッケージ直下にクラスがあるかのように見せかけることができますが、Pythonの型システム上では依然としてモジュール層が残っています。

hogepackage/__init__.py:

#!/usr/bin/env python3
from .foo import Foo
from .bar import Bar

>>> from hogepackage import Foo
>>> type(Foo())
<class 'hogepackage.foo.Foo'>

これはリフレクション上の混乱を招きますし、sphinxのようなドキュメントツールもこの階層のままドキュメントを生成してしまいます。

一方、以下のようにすることで型システム上でも期待通りのクラス構成を実現できることが分かりました。

hogepackage/__init__.py:

#!/usr/bin/env python3
import sys
import os
import codecs

dir = os.path.dirname(os.path.abspath(__file__))
with codecs.open(dir + '/foo.py', 'r', 'utf-8'): as file:
    exec(''.join(file.readlines()))
with codecs.open(dir + '/bar.py', 'r', 'utf-8'): as file:
    exec(''.join(file.readlines()))

>>> from hogepackage import Foo
>>> type(Foo())
<class 'hogepackage.Foo'>

ただ、これはあまりにも強引な解決法のように見えます。
もっとよい解決方法はないでしょうか？

Comments

[tachikoma]

どうするのがいいのかすぐ分かりませんが、例えばpandasのDataFrameは何もしてなかったりしますね。
>>> import pandas
>>> type(pandas.DataFrame())
pandas.core.frame.DataFrame

[hayataka2049]

割と何もしないのが普通なんじゃと思い始めました。
>>> from sklearn.svm import SVC
>>> SVC
<class 'sklearn.svm.classes.SVC'>
sphinxはsphinx側でうまいこと設定できないのか・・・

[t_obara]

確かにDataFrameなど参考になりますよね。C/C++のような一ファイル一クラスといった認識ではなく、一つのpy（foo/barなど）はnamespaceでまとめられた機能群と考えるのがPython流なのではないかと。(なので、解決方法というよりはそれに合った構成にすべきではという意図になります）
ただ、一ファイルが大きくなる傾向が出るので、質問されたように適切に分離したくなるかとは思いますが、その場合も機能毎に分割するようなリファクタリングをするのが良いのではないかと。

Answer 1

リフレクション上の混乱を招きます

気持ちはわかるのですが、Pythonを使っている限り、サードパーティーのライブラリを使っていて頻繁に起こることなので(tachikoma さんの補足の通り)自分が書くプログラムで気にしていてもしょうがないと思いました。

---

さて。

https://docs.python.org/ja/3.6/reference/datamodel.html#index-34

なんと__module__属性は書き換え可能(!)なので、クラスを定義したあとで差し替えてしまうと、別のモジュールに属させることが可能です。

hogepackage/_ init _.py

from .bar import Bar
from .foo import Foo

hogepackage/foo.py

class Foo:
    def __init__(self) -> None:
        super().__init__()
        self.data = 'Foo'

Foo.__module__ = 'hogepackage'

hogepackage/bar.py

class Bar:
    def __init__(self) -> None:
        super().__init__()
        self.data = 'Bar'

Bar.__module__ = 'hogepackage'

main.py

#!/usr/bin/env python
import pickle
from hogepackage import Foo, Bar


def main():
    f = Foo()
    b = Bar()

    print(f)
    print(type(f))
    print(pickle.dumps(f))
    print(pickle.loads(pickle.dumps(f)))
    print()
    print(b)
    print(type(b))
    print(pickle.dumps(b))
    print(pickle.loads(pickle.dumps(b)))


if __name__ == '__main__':
    main()

結果

<hogepackage.Foo object at 0x104d9f358>
<class 'hogepackage.Foo'>
b'\x80\x03chogepackage\nFoo\nq\x00)\x81q\x01}q\x02X\x04\x00\x00\x00dataq\x03X\x03\x00\x00\x00Fooq\x04sb.'
<hogepackage.Foo object at 0x104e01be0>

<hogepackage.Bar object at 0x104ddf400>
<class 'hogepackage.Bar'>
b'\x80\x03chogepackage\nBar\nq\x00)\x81q\x01}q\x02X\x04\x00\x00\x00dataq\x03X\x03\x00\x00\x00Barq\x04sb.'
<hogepackage.Bar object at 0x104e01a20>

---

私自身は、他人が見て何のためにやっているのかわからないコードや、どんな副作用があるか考えるのが面倒なコード、将来にわたって動作するか怪しいコードを差し挟むのは気持ち悪いと思います。
それに対して見合うメリットは感じません。

Comments

[GlassGrass]

pythonの流儀は別にして、技術的な解決手順としてはこれが一番無難みたいですね。
とはいえやっぱり流儀には従ったほうがいいとも思うので実用に関しては再考してみます。

Answer 2

こんなやり方でいかがでしょうか。

import imp

imp.load_source('hogepackage', 'foo.py')
imp.load_source('hogepackage', 'bar.py')

from hogepackage import Foo
print(type(Foo()))

結果

<class 'hogepackage.Foo'>

Deprecation Warningが出るとのことですので、importlibを使った場合

from importlib.machinery import SourceFileLoader


SourceFileLoader('hogepackage', 'foo.py').load_module()
SourceFileLoader('hogepackage', 'bar.py').load_module()

from hogepackage import Foo, Bar
print(type(Foo()))
print(type(Bar()))

でも、名前空間の管理のためにやるのはやめたほうがいいでしょうね。確認していませんがPyCharmなどIDEの支援をあえて放棄することになるでしょうし、静的解析をするツールも動くと思えません。プラグインとかダイナミックにソースをロードしたいとか、フレームワークを作るとか特殊な用途です。

Comments

[tachikoma]

こういう方法もあるんですね。impはDeprecation Warningが出てしまうので、importlibで同様のことができるとなおよさそうですね。

Answer 3

namespaceを同じにするのではダメなんでしょうか

Comments

[hayataka2049]

それをどうやって実現すればいいか？（そもそもできるのか？）という質問だと思いますが。

[_Victorique__]

同意ですね。
namespaceが本来の意味をなしていない気がします。

[yuba]

C#ならばできるのですが、Pythonではディレクトリファイルツリー構造が名前空間ですからね。

[Kenji.Noguchi]

（コメント削除。趣旨を勘違いしました）

Answer 4

これはリフレクション上の混乱を招きますし、sphinxのようなドキュメントツールもこの階層のままドキュメントを生成してしまいます。

私だったら、これらのデメリットは目をつむって当初のやり方で実装します。

が、あえて手を加えるのであれば、

# hogepackage/__init__.py
from . import foo

class Foo(foo.Foo):
	pass

というように、継承クラスを作ってはいかがですか。
sphinxは使った事がないのでどのようにドキュメントが作成されるかはわかりませんが、継承情報ぐらいはなんとかしてくれる。…といいなぁ…。