Python ウェブフレームワークの現況¶
全体的な状況はこんな感じらしい。
Django, Flask がやはり人気があるようだが、 これらは URLルーティング + ORマッピングなデザインだから 個人的には興味がない。
ただし、Django には GeoDjango というものがあるようで、 これは DB に PostGIS などを用いて空間情報を扱えるようにした 拡張らしい。暇で暇で仕方が無いような時があったら調べてみよう。
オブジェクト指向（的）のフレームワークとしては
CherryPy
Grok, Dolmen
Pyramid, Substance D
が見つかった。
CherryPy¶
PythonのWebフレームワーク「CherryPy」 に依ると、これはURL解決にトラバース方式を採用している。
データベースについてはフレームワークとして何もサポートしていないようで、 自分で好きなものを選んで自力で使え、ということのようだ。 例えばこの チュートリアル では sqlite3 をインポートして直接 SQL を投げている。 PyPI に CherryPy 用 SQLArchemy ツールがあるので、 そういうものを組み込めばいいのか。
Zope だとデータベースへのアクセスはフレームワークが一手に処理してくれて、 それに慣れていると、自分でデータベース周りのコードを書かなくちゃいけないのは 不安で仕方ない（トランザクション処理とかが不十分になりそうで）。
最新版は 3.6.0 (2014-09-14)。
Grok, Dolmen/Cromlech¶
Zope 3 の発展系。
Grok は Zope 3 に対して
ZCML を減らす（代わりに python コード中に書く）
ファイル構成やクラス名などに関する暗黙の規約を導入する
という変更を加えたもの。ZTK の上に grokcore.* とか megrok.* とかの ラッパーをかぶせている、という感じか。
この変更が便利かどうかは場合によるような気がする。ZCML は コントロールをモデルとビュー（python コード）から分離するのに良い仕掛けであると 思うのだが、まぁ確かに面倒と言えば面倒くさい。 単純なアプリを作るんだったら混ぜこぜの方が楽かも知れない。
Dolmen/Cromlech は Grok を元に派生した亜種で、 公式サイト に拠ると、implementaion と definition の厳密な分離を指向しているらしい。 詳細な記述がないので精確な意味は理解できないが、Zope 3 の開発経験から 想像するに、モデルとビューの役割分担が曖昧なところを問題視しているのだろう。 http request を受けて処理するのはビューなので、データ処理コードは ついついビューに書きがちで、モデルの内部構造に依存したコードを 書いてしまう。つまりカプセル化を軽視してしまう傾向がある。 Dolmen/Cromlech がこれをどのような方法で回避しようとしているのか、 サンプルコードもチュートリアルも見当たらないので解らない。
現在の開発状況はよく解らない。 専用の PyPI らしきところを見ると、細々とアップデートされているようだが。
Pyramid, Substance D¶
Pyramid は Django や Zope にインスパイアされた折衷的フレームワークで あるらしい。Django のように URLルーティング + ORマッビング方式にもできるし、 Zope のようにトラバーサル + オブジェクト指向DB にもできる。 Grok のようにデコレータを使ってもいいし、Zope のように ZCML で コントロールすることもできる。
特に、ZODB に対応しており、プロジェクト生成時に選択できることは 個人的には重要な点である。
開発は活発で、ユーザも多そうだ。ただし Zope 的に使っている人が どれくらい居るのか不明。
Substance D は、Pyramid 上で動くアプリケーションサーバで、公式サイトで 記されている通り、 Zope 2 に似ている。 データベースには ZODB を使うようだ。
正式リリース版というものは存在せず、ひたすら Github 上で開発が続いている らしい。既に充分に実用的なのだろうか。ユーザがどれだけ居るのかも 判らない。
っと、twitter に "#SubstanceD release coming soon" と流れているな。