Python を Web 上で使うには
**************************

著者:
   Marek Kubica


概要
^^^^

このドキュメントは Python を web 向けに使う方法を示します。 Python を
web サーバとともに利用するためのいくつかの方法や web サイトを開発する
際の一般的なプラクティスを示します。

web サイトのコンテンツをユーザが作るということに焦点を当てた "Web 2.0"
の提起以来 Web プログラミングは人気の話題となっています。 Python を使
って web サイトを作れましたが、それはやや退屈な作業でした。 そのため、
開発者がサイトを速く、頑強に作るのを助けるために多くのフレームワークと
補助ツールが作成されました。 この HOWTO では動的なコンテンツを作成する
ために Python と web サーバを結合させるいくつかの方法について述べます
。 この話題は非常に広過ぎてドキュメント 1 つだけでは網羅しきれないため
、この HOWTO を完全な入門書とするつもりはありません。 ここでは最も人気
のあるライブラリの簡単な概要を述べます。

参考: この HOWTO は Python を web 上で使う方法の概要を扱おうとしてい
  ますが 、HOWTO が常に望みどおりに最新の状況を伝えられるわけではあり
  ません。 Python での web 開発は急速に発展しています、そのため Wiki
  ページ Web Programming に多くの最新の開発に関する内容があるでしょう
  。


低レベルから見て
================

ユーザが web サイトを訪れた時、ブラウザはサイトの web サーバとコネクシ
ョンを形成します (これは *リクエスト* と呼ばれます)。サーバはファイル
システム上からファイルを探し出し、ユーザのブラウザにそれを送り返し、ブ
ラウザが表示します (これが *レスポンス* です)。これが基礎となるプロト
ロル、HTTP のおおまかな動作です。

さて、動的な web サイトはファイルシステム上のファイルではなく、リクエ
ストが来たときに web サーバが実行するプログラムの上に作られていて、こ
のプログラムがユーザへ返すコンテンツを *生成* します。 それらは掲示板
の投稿を表示したり、メールを表示したり、ソフトウェアの設定や現在時刻の
表示などの様々な便利なことができます。 これらのプログラムはサーバがサ
ポートするあらゆる言語で書くことができます。 ほとんどのサーバが Python
をサポートしているので、動的な web サイトを作成するのに Python を利用
することは簡単です。

ほとんどの HTTP サーバは C や C++ で書かれていて、これらは Python コー
ドを直接は実行できず、サーバとプログラムの間にブリッジが必要です。 こ
れらのブリッジやインターフェースはプログラムがサーバとどうやりとりする
かを定めます。 これまでに最良のインターフェースを作成するために膨大な
数の試みがなされてきましたが、触れる価値のあるものはわずかです。

全ての web サーバが全てのインターフェースをサポートしているわけではあ
りません。多くの web サーバは古い、現在では撤廃されたインターフェース
のみをサポートしています; しかし、多くの場合にはサードパーティーモジュ
ールを利用して新しいインターフェースをサポートするように拡張できます。


Common Gateway Interface
------------------------

一般に "CGI" と呼ばれるこのインターフェースは最も古く、ほとんどの web
サーバでサポートされ、すぐに使うことができます。 CGI を利用して web サ
ーバと通信するプログラムはリクエスト毎に起動される必要があります。 そ
のため毎回のリクエストは新しい Python インタプリタを起動します -- この
ため起動にいくらか時間がかかります -- そしてこのインターフェースは負荷
が低い状況にのみ向いています。

CGI の利点は単純だということです -- CGI を利用するプログラムを書くのは
3行のコードを書くだけです。しかし、この単純さは後で高くつきます; 開発
者を少ししか助けてくれません。

CGI プログラムを書くことは可能ではありますが、もはや推奨されません。
WSGI (詳しくは後で述べます) では CGI をエミュレートするプログラムを書
くことができるので、よりよい選択肢が選べない場合には CGI としてプログ
ラムを実行できます。

参考: Python の標準ライブラリには簡素な CGI プログラムを作成するのを
  助ける いくつかのモジュールが含まれています:

  * "cgi" -- CGI スクリプトでのユーザ入力を扱います

  * "cgitb" -- CGI アプリケーションの中でエラーが発生した場合に、
    "500 Internal Server Error" メッセージの代わりに親切なトレースバッ
    クを 表示します

  Python wiki では CGI scripts にあるページに Python での CGI に関して
  追加情報を取り上げています。


CGI をテストするための単純なスクリプト
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CGI が web サーバで動くかどうかを調べるのに、この短く単純な CGI プログ
ラムが利用できます:

   #!/usr/bin/env python
   # -*- coding: UTF-8 -*-

   # enable debugging
   import cgitb
   cgitb.enable()

   print "Content-Type: text/plain;charset=utf-8"
   print

   print "Hello World!"

web サーバの設定に依存して、このコードを ".py" もしくは ".cgi" 拡張子
をつけたファイルに書く必要があります。 それに加えて、セキュリティ上の
理由のため、ファイルは "cgi-bin" フォルダ内に置く必要があるかもしれま
せん。

"cgitb" 行が何なのか疑問に思うかもしれません。 この行は、クラッシュし
てブラウザで "Internal Server Error" と表示する代わりに、親切なトレー
スバックを表示できるようにします。 これはデバッグの際に便利ですが、い
くつかの機密データをユーザにさらけ出すリスクにもなりえます。 そういっ
た理由で、スクリプトを完成品として利用する準備ができたら "cgitb" は使
ってはいけません。 さらに、*常に* 例外を捕捉し、適切なエラーページを表
示するようにしなければいけません -- エンドユーザは得体の知れない
"Internal Server Errors" をブラウザで見ることを好みません。


自身のサーバで CGI を立ち上げる
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

自身の web サーバを持っていない場合には、この内容は当てはまりません。
そのままで動作するか調べることは可能で、もし動作しない場合は、とにかく
web サーバの管理者と話し合う必要があります。 大きなホストである場合、
チケットに記入して Python サポートを求められるでしょう。

あなた自身が管理者であるか、自身のコンピュータで試すためにインストール
したい場合には自分自身で設定する必要があります。 異なる設定オプション
を持つ web サーバがたくさんあるため、CGI の設定法はひとつではありませ
ん。 現在最も広く使われている web サーバは  Apache HTTPd 、略して
Apache です。 Apache はほぼ全てのシステムにパッケージ管理ツールを使っ
て簡単にインストールできます。 lighttpd はもう一つの選択肢で、パフォー
マンスがより優れているといわれています。 多くのシステムでこのサーバは
パッケージ管理ツールを利用してインストールできるので、web サーバを手動
でコンパイルする必要はないでしょう。

* Apache ではチュートリアル Dynamic Content with CGI を参照でき、こ
  れ には全てが解説されています。 ほとんど場合には "+ExecCGI" を設定す
  れ ば十分です。 このチュートリアルはよくでくわす可能性のある落し穴に
  つ いても書かれています。

* lighttpd では CGI module を使う必要があり、この設定は分かりやすい
  で す。 結局のところ、"cgi.assign" を適切に設定することになります。


CGI スクリプトでの一般的な問題
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CGI を利用していると、スクリプトを走らせようとするときにちょっといらい
らすることがときどきあります。 あるときは一見正しいスクリプトが期待ど
おりに動かないことがあり、気付くのが難しい小さな隠れた問題が原因だった
りします。

いくつかの潜在的な問題は次の通りです:

* Python スクリプトが実行可能でない。 CGI スクリプトが実行可能でない
  と き、多くの web サーバは実行しユーザに出力を送る代わりに、ユーザが
  ダ ウンロードできるようにします。 CGI スクリプトが Unix 系 OS で適切
  に 実行されるために "+x" ビットが設定される必要があります。 "chmod
  a+x your_script.py" を使うことで問題は解決するでしょう。

* Unix 系システムでは、プログラムファイルの行末は Unix 形式でなけれ
  ば なりません。 web サーバはスクリプト最初の行 (shebang と呼ばれます
  ) を調べ、そこで指定されたプログラムを実行しようとするため、ここが重
  要 なのです。 これは Windows の行末 (Carriage Return & Line Feed、ま
  た は CRLF) によって簡単に混乱させられるので、ファイルの行末を Unix
  の 行末 (Line Feed, LF のみ) に変換する必要があります。 これは FTP
  経由 でバイナリモードではなくテキストモードでファイルをアップロード
  すると 自動的に行なわれますが、単に Unix 行末で保存するようテキスト
  エディタ に指示する方が望ましいです。 ほとんどのエディタはこの機能を
  サポート しています。

* web サーバはファイルが読めなければならないので、パーミッションが適
  切 になっているか確認する必要があります。 Unix 系システムでは、サー
  バは しばしば "www-data" ユーザ、 "www-data" グループのパーミッショ
  ンで実 行されているので、ファイルの所有権を変更したり、 "chmod a+r
  your_script.py" を使いファイルを誰からでも読み込み可能にしたりするの
  は試す価値があります。

* web サーバはアクセスを試みているファイルが CGI スクリプトであると
  い うことを知っていなければなりません。 web サーバが CGI スクリプト
  に対 し、ある特定のファイル拡張子を持つことを要求するよう設定されて
  いない か設定を確認して下さい。

* Unix 系システムでは、 shebang にあるインタプリタへのパス
  ("#!/usr/bin/env python") は正確でなければなりません。 この行は
  Python を見つけるために "/usr/bin/env" を呼び出しますが、
  "/usr/bin/env" が無いか Python が web サーバのパスに無い場合は失敗し
  ます。 Python がどこにインストールされているか分かっている場合、その
  フルパスを使うこともできます。 "whereis python" コマンドと "type -p
  python" コマンドも Python がどこにインストールされたかを探すのに役立
  つでしょう。 一旦パスが分かれば、shebang 行をそれに応じて変更できま
  す: "#!/usr/bin/python"。

* ファイルは BOM (Byte Order Mark) を含んでいてはいけません。 BOM は
  UTF-16 と UTF-32 エンコーディングのバイト順を決定するのに利用されま
  すが、あるエディタは UTF-8 ファイルにも BOM を書き込むことがあります
  。 BOM は shebang 行に影響するので、エディタが BOM を書き込まないよ
  うにしてください。

* web サーバが mod_python を使っている場合、 "mod_python" が問題とな
  る ことがあります。 "mod_python" はそれ自身で CGI スクリプトを扱うこ
  と ができますが、そのことが問題の原因となることがあります。


mod_python
----------

PHP から来た人達はしばしば、Python を web 上で利用する方法を把握するの
に苦労します。 彼らが最初に考えるのはたいてい mod_python のことで、そ
れは "mod_python" が "mod_php" と同等のものだと考えるからです。 しかし
実際にはたくさんの相違点があります。 "mod_python" が行なうことは
Apache プロセスへのインタプリタの埋め込みで、そのためリクエストごとに
Python インタプリタを起動させる必要が無いので、リクエストに対する速度
が向上します。 一方で PHP でよくやるような「HTML への Python の埋め込
み」とはかけ離れています。 Python でそれと同等なことをするのはテンプレ
ートエンジンです。 "mod_python" 自身はより強力で Apache 内部に対してよ
り多くのアクセスを提供します。 CGI をエミュレートし、JSP に似た「HTML
への Python 埋め込み」である "Python Server Pages" モードで動作でき、
全てのリクエストを一つのファイルで受け付けて何を実行するを決める
"Publisher" を持っています。

しかし、"mod_python" はいくつかの問題も抱えています。 PHP インタプリタ
と違い Python インタプリタはファイル実行時にキャッシュを利用するため、
ファイルの変更時にはアップデートするには web サーバ全体を再起動する必
要があります。 もう一つの問題は基本的なコンセプトにあります -- Apache
はリクエストを扱うためにいくつかの子プロセスを起動し、不幸にも全ての子
プロセスが Python インタプリタ全体を、利用しない場合であっても、読み込
む必要があるのです。 このせいで web サーバ全体が遅くなります。 別の問
題は "mod_python" は特定のバージョンの "libpython" に対してリンクされ
るため、"mod_python" を再コンパイルせずに古いバージョンから新しいバー
ジョンに切り替える (例えば 2.4 から 2.5) ことはできません。 さらに
"mod_python" は Apache web サーバとも結び付いているため "mod_python"
用に書かれたプログラムは他の web サーバで簡単に動かすことはできません
。

これらが新しくプログラムを書く際に "mod_python" を避けるべき理由です。
いくつかの状況では "mod_python" を利用するのはよいアイデアでしょうが、
WSGI は "mod_python" 下でも WSGI プログラムを同様に動かせます。


FastCGI と SCGI
---------------

FastCGI と SCGI は CGI のパフォーマンス上の問題を別の方法で解決しよう
という試みです。 web サーバにインタプリタを組み込む代わりに、バックグ
ラウンドで長時間実行されるプロセスを生成します。 さらに web サーバ上に
はいくつかのモジュールがあり、それらは web サーバとバックグラウンドプ
ロセスが「話す」ことを可能にします。 バックグラウンドプロセスはサーバ
と独立しているため、 Python を含んだ、任意の言語で書くことができます。
言語に必要なのは web サーバとの通信を扱うライブラリだけです。

FastCGI と SCGI の違いはささいなもので、SCGI は基本的に "simpler
FastCGI" です。しかし、SCGI をサポートする web サーバは限定されている
ため、多くの人々は代わりに同様に動作する FastCGI を利用します。SCGI に
適用されるほとんど全てのものは FastCGI にも適用できるので、 FastCGI だ
けについて解説します。

最近では FastCGI を直接使うことはありません。 "mod_python" のように
WSGI アプリケーションの配置のためだけに FastCGI が利用されています。


FastCGI のセットアップ
~~~~~~~~~~~~~~~~~~~~~~

web サーバに応じて特別なモジュールが必要となります。

* Apache には mod_fastcgi と mod_fcgid の両方があります。
  "mod_fastcgi" が最初に作られましたが、非フリーとして扱われるという、
  いくつかのライ センスの問題があります。"mod_fcgid" はより小さく、前
  者と互換性があり ます。このうちのどちらかを Apache から読み込む必要
  があります。

* lighttpd は自身に FastCGI module を含んでいて、SCGI module も同様
  に 含んでいます。

* nginx も FastCGI をサポートしています。

一旦モジュールをインストールして設定したら、以下の WSGI アプリケーショ
ンを使ってテストできます:

   #!/usr/bin/env python
   # -*- coding: UTF-8 -*-

   from cgi import escape
   import sys, os
   from flup.server.fcgi import WSGIServer

   def app(environ, start_response):
       start_response('200 OK', [('Content-Type', 'text/html')])

       yield '<h1>FastCGI Environment</h1>'
       yield '<table>'
       for k, v in sorted(environ.items()):
           yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v))
       yield '</table>'

   WSGIServer(app).run()

This is a simple WSGI application, but you need to install flup first,
as flup handles the low level FastCGI access.

参考: setting up Django with WSGI にドキュメントがあり、その多くは
  WSGI 互 換フレームワークやライブラリで再利用できます。 "manage.py"
  の部分を 変更するだけで、ここで使った例を利用できます。 Django もほ
  とんど同様 のことを行います。


mod_wsgi
--------

mod_wsgi は低レベルなゲートウェイから脱するための試みです。 FastCGI、
SCGI、mod_python は主に WSGI アプリケーションを配置するために使われる
と仮定し、mod_wsgi は WSGI アプリケーションを直接 Apache web サーバに
埋め込むために開発が開始されました。 mod_wsgi は WSGI アプリケーション
をホストするために特別に設計されています。 これにより WSGI アプリケー
ションの配置は、グルーコードが必要な他の低レベルな手法を使った配置より
も非常に簡単になります。 mod_wsgi の欠点は Apache web サーバに制限され
てしまうことです; 他のサーバではそれ用の mod_wsgi の実装が必要になるで
しょう。

mod_wsgi は2つのモードをサポートします: 埋め込みモード (embeded mode)
は Apache プロセスとデーモンプロセスを統合するもので、 FastCGI に似て
います。 FastCGI と違って、 mod_wsgi はそれ自身がワーカープロセスを取
り扱うので管理が楽になります。


後ろに下って: WSGI
==================

WSGI について何度も言及してきたため、なにか重要そうに感じたでしょう。
実際に重要なので、ここで説明します。

*Web Server Gateway Interface* 、略して WSGI は **PEP 333** で定義され
ていて、現在のところ Python で web プログラミングをする最良の方法です
。 WSGI はフレームワークを書くプログラマにとっては優れている一方、普通
の web プログラマが直接触れる必要の無いものです。 web 開発のフレームワ
ークを選ぶときに、 WSGI をサポートしているもの選ぶことは素晴しい考えで
す。

WSGI の大きな利点は、アプリケーションプログラミングインターフェース
(API) が統一されることです。 プログラムが WSGI と互換性があれば -- こ
れは外部から見たときにフレームワークが WSGI をサポートしているというこ
とになります -- そのプログラムは WSGI ラッパーのある全ての web サーバ
インターフェースを通して利用できます。 ユーザが mod_python や FastCGI
や mod_wsgi のうちどれを利用しているかを気にせずにすみます -- WSGI を
使うことで任意ゲートウェイインターフェース上で動作するようになります。
Python 標準ライブラリには、テストのために利用できる小さな web サーバで
ある、独自の WSGI サーバ "wsgiref" が含まれています。

WSGI の本当に卓越している機能はミドルウェアです。 ミドルウェアとはプロ
グラムに様々な機能性を加えられるレイヤーのことを指します。 無数の ミド
ルウェア が利用可能になっています。 例えば自前でセッション管理を書く
(HTTP はステートレスなプロトコルなので、複数の HTTP リクエストを単一の
ユーザに関連付けるために、アプリケーションがセッションによって状態を作
成し管理しなければなりません) 代わりに、セッション管理をしてくれるミド
ルウェアをダウンロードし、動作させ、アプリケーション独自の部分をコーデ
ィングするだけです。 圧縮についても同じです -- HTML の gzip 圧縮をする
既存のミドルウェアがあって、これでサーバの帯域を節約できます。 認証も
既存のミドルウェアで簡単に解決できる問題です。

WSGI は複雑に思えるかもしれませんが、学習の始めの段階は非常に価値もの
になります。 というのも WSGI とそれに関連したミドルウェアには、 web サ
イトを開発している中で起きる多くの問題の解決策が備わっています。


WSGI サーバ
-----------

CGI や mod_python などの様々な低レベルゲートウェイに接続するためのコー
ドを *WSGI サーバ* と呼びます。 こういったサーバの一つに "flup" があり
、これは FastCGI、SCGI に加えて AJP もサポートしています。 これらのサ
ーバのいくつかは "flup" のように Python で書かれていますが、C で書かれ
たものもあり、それらは気軽に置き換えることができます。

多くのサーバが既に利用可能なので、 Python の web アプリケーションはほ
とんどどこにでも配置できます。 これは他の web テクノロジーと比べたとき
の Python の大きな利点の 1 つです。

参考: WSGI homepage では WSGI 関係のコードの素晴しい概要が読め、
  WSGI をサ ポートする *全ての* アプリケーションが利用できる WSGI サー
  バ の広大 なリストがあります。

  標準ライブラリに含まれる WSGI をサポートするモジュールに興味が湧いた
  かもしれません、すなわちこのモジュールのことです:

  * "wsgiref" -- WSGI のためのいくつかの小さなユーティリティとサーバ


事例研究: MoinMoin
------------------

WSGI は web アプリケーションプログラマに何をもたらしてくれるのでしょう
か? WSGI を使わずに Python で書かれた昔からある web アプリケーションを
みてみましょう。

最も広く使われている wiki ソフトウェアパッケージの一つに MoinMoin があ
ります。 これは2000年に作られたため、WSGI より3年ほど先行していました
。 古いバージョンでは CGI、mod_python、FastCGI、スタンドアロンで動作す
るためには別々のコードが必要でした。

現在では WSGI をサポートしています。 WSGI を使うことで、グルーコードを
追加せずに WSGI に準拠したサーバに MoinMoin を配置できるようになりまし
た。 WSGI 対応前のバージョンとは違って、 MoinMoin の開発者が全く知らな
い WSGI サーバを MoinMoin に含めることができます。


モデル・ビュー・コントローラ (Model-View-Controller)
====================================================

*MVC* という用語は「フレームワーク *foo* は MVC をサポートしています」
というような文句でよく聞きます。 MVC は特定の API というよりは、コード
の総合的な構造についての話です。 多くの web フレームワークはこのモデル
を使い、開発者がプログラムに構造を与えることを助けています。 大きな
web アプリケーションはコード量が増えるので、最初からプログラムによい構
造を持たせることはよい考えです。 そうすることで、他のフレームワークの
ユーザであっても (MVC は Python 特有のものではないので、他の言語であっ
ても)、既に MVC 構造に馴染んでいるため、コードを簡単に理解できます。

MVC は 3 つの構成要素からできています:

* *モデル* (model) 。 これは表示したり変更されたりするデータのことで
  す 。 Python のフレームワークでは、この要素は object-relational マッ
  パ ーが利用するクラスで表現されます。

* *ビュー* (view) 。 この構成要素の仕事は、モデルのデータをユーザに
  表 示することです。 典型的にはこの要素はテンプレートで実装されます。

* *コントローラ* (controller) 。 これはユーザとモデルの間にあるレイ
  ヤ ーです。 コントローラは (ある特定の URL を開くというような) ユー
  ザの 動作に反応し、必要に応じてモデルにデータを変更するよう伝え、ビ
  ューの コードに何を表示するかを伝えます。

MVC を複雑なデザインパターンだと考える人もいるかもしれませんが、実際は
そうではありません。Python で使われているのは、それがきれいで保守可能
な web サイトを作成するのに便利だということがわかっているからです。

注釈: 全ての Python フレームワークが明示的に MVC をサポートしている
  わけで はありませんが、データロジック (モデル) とユーザとのインタラ
  クション ロジック (コントローラ) とテンプレート (ビュー) を分離して
  、 MVC パ ターンを使っている web サイトを作成することは普通のことで
  す。 その理 由はテンプレートに不必要な Python コードを書かないことが
  重要なことだ からです --  そのようなコードは MVC に反する動作をして
  大混乱を生み、 それを理解して修正することがいっそう難しくなります。

参考: Wikipedia の英語版には Model-View-Controller pattern について
  の記事 があります。 この記事には様々なプログラミング言語での web フ
  レームワ ークの長大なリストが載っています。


web サイトの要素
================

web サイトは複雑な構造物なので、 web 開発者がコードを書きやすく、保守
しやすくする助けとなるツールが作られてきました。 このようなツールは、
全ての言語の全ての web フレームワークについて存在します。 開発者はこれ
らのツールを強制的に使わされるわけではないし、「最良の」ツールはたいて
いは存在しません。 しかし、これらの利用可能なツールは web サイトの開発
プロセスを非常に単純にしてくれるので、学ぶ価値はあります。

参考: このドキュメントで述べられるよりも多くの要素があります。
  Python wiki には Web Components と呼ばれる、これらの要素についてのペ
  ージがありま す。


テンプレート
------------

HTML と Python コードを混在させることは、いくつかのライブラリを利用す
ることで可能になります。 最初は便利なのですが、こうしてしまうとコード
が恐ろしく保守不可能となります。 これがテンプレートが存在する理由です
。 テンプレートは、最も単純な場合には、単にプレースホルダーを持つ HTML
ファイルとなります。 プレースホルダーを埋めた後に HTML はユーザのブラ
ウザに送信されます。

Python には既に単純なテンプレートを作る 2つの手段があります:

   >>> template = "<html><body><h1>Hello %s!</h1></body></html>"
   >>> print template % "Reader"
   <html><body><h1>Hello Reader!</h1></body></html>

   >>> from string import Template
   >>> template = Template("<html><body><h1>Hello ${name}</h1></body></html>")
   >>> print template.substitute(dict(name='Dinsdale'))
   <html><body><h1>Hello Dinsdale!</h1></body></html>

単純でないモデルのデータに基づいて複雑な HTML を生成するために、たいて
い Python の *for* や *if* のような条件分岐や反復といった構造が必要と
されます。 *テンプレートエンジン* はこのような複雑さを持つテンプレート
をサポートします。

Python には多くのテンプレートエンジンがあり、framework とともに、また
は独立に利用できます。 いくつかのテンプレートエンジンでは、利用用途を
狭めて学びやすくしてあるプレーンテキストのプログラミング言語を定義して
います。 他のテンプレートエンジンでは XML を利用しているものもあり、テ
ンプレートの出力が常に有効な XML になるよう保証されています。 これ以外
にも非常に多くの種類があります。

独自のテンプレートエンジンを提供する frameworks もあれば、ある特定のテ
ンプレートエンジンを推奨するものもあります。 別のテンプレートエンジン
を使う理由が無ければ、フレームワークが提供もしくは推奨するものを使うの
がよい考えです。

人気のあるテンプレートエンジンには次のようなものがあります:

   * Mako

   * Genshi

   * Jinja

参考: たくさんのテンプレートエンジンが注目を集めようと競っています。
  とい うのも、 Python でテンプレートエンジンを作るのが非常に簡単だか
  らです 。 wiki の Templating ページには、大量の今も増え続けるテンプ
  レートエ ンジンの一覧が載っています。 上で挙げた 3 つのテンプレート
  エンジンは "次世代の" テンプレートエンジンと見なされていて、始めるの
  に良いもの です。


データの永続化
--------------

*データの永続化 (data persistence)* とは非常に複雑に聞こえますが、単に
データを保存するだけです。 このデータはブログエントリのテキストだった
り、掲示板の投稿だったり、wiki ページのテキストだったりします。 もちろ
ん、 web サーバに情報を保存するたくさんの様々な方法があります。

しばしば MySQL や PostgreSQL のような関係データベースエンジンが利用さ
れます。 それは数百万エントリに及ぶ非常に大きなデータベースを優れたパ
フォーマンスで扱うことができるためです。SQLite と呼ばれる小さなデータ
ベースエンジンもあり、これは "sqlite3" モジュールによって Python にバ
ンドルされていて、ファイルを一つだけしか使いません。 これ以外の依存関
係はありません。 小さめのサイトに対しては SQLite で十分です。

関係データベースには SQL と呼ばれる言語を利用して *問い合わせ (query)*
ます。 一般的に Python プログラマは SQL があまり好きではなく、オブジェ
クトで動作する方を好みます。 ORM (Object Relational Mapping) と呼ばれ
る技術を使うことで、 Python オブジェクトをデータベースに保存できます。
ORM は内部でオブジェクト指向的アクセスを SQL コードに変換するので、ユ
ーザはそのことを意識せずに済みます。 ほとんどの framework は ORMs を利
用し、とてもうまくいっています.

第2の可能性は通常のプレーンテキストのファイル (しばしば "フラットファ
イル" と呼ばれます) で保存することです。 この方法は単純なサイトでは非
常に簡単ですが、 web サイトが保存されたデータへの更新がたくさん行われ
る場合、ちゃんと動くようにするのは難しくなってきます。

第3の可能性はオブジェクト指向データベースです ("オブジェクトデータベー
ス" とも呼ばれます)。 このデータベースは、プログラムの実行中のメモリ上
での構成とほぼ同じ形式でオブジェクトのデータを保存します。 (対照的に、
ORM はオブジェクトデータをテーブルの行と行どうしの関係として保存します
。) オブジェクトを直接保存することには、ほぼ全てのオブジェクトを単純な
方法で保存できるという優位点があり、これは表現するのが非常に難しいオブ
ジェクトがある関係データベースには無い特徴です。

framework はしばしばどのデータストレージ方法を選べばよいかのヒントを与
えてくれます。 代わりとなるストレージ機構を使った方がアプリケーション
の特別な要件によりよく合うのでない限り、普通はフレームワークが推奨して
いるデータストアを使い続けるのがよい考えです。

参考:

  * Persistence Tools にはファイルシステムにデータを保存する方法が列
    挙 されています、これらのモジュールの内のいくつかは標準ライブラリ
    の一 部です

  * Database Programming はデータ保存の方法を選ぶのを助けてくれます

  * SQLAlchemy, the most powerful OR-Mapper for Python, and Elixir,
    which makes SQLAlchemy easier to use

  * SQLObject は別の人気のある OR マッパーです

  * ZODB と Durus の二つはオブジェクト指向データベースです


フレームワーク
==============

web サイトを動かずコードを作成するプロセスは様々なサービスを提供するコ
ードを書く作業を伴います。 あるサービスを提供するコードは、当該の web
サイトの複雑さや目的に関わらず、たいてい同じような動作をします。 共通
のソリューションを抽象化し再利用可能なコードにすると、 web 開発で "フ
レームワーク" と呼ばれるものが生み出されます。 おそらく最も知られてい
る web 開発のフレームワークは Ruby on Rails ですが、 Python には独自の
フレームワークがあります。 その中には部分的に Rails にインスパイアされ
たり、アイディアを拝借したものもありましたが、多くのものは Rails より
ずっと前から存在していました。

もともと Python の web フレームワークには、 web サイトを開発するのに必
要な全てのサービスを1つにまとめて、巨大な集約されたツールの集まりを作
る傾向がありました。 どの2つの web フレームワークも互換性はありません
でした: あるフレームワーク用に開発したプログラムは、かなりの再設計作業
をしないと他のフレームワークには配置できませんでした。 この状況が "ミ
ニマリスト" web フレームワークの開発につながり、そういったフレームワー
クは Python コードと http プロトコルの間のやり取りをするツールだけを提
供し、他の全てのサービスを別々のコンポーネントとしてフレームワーク上に
追加するものでした。 場当たり的な標準が開発され、制限はあるものの、異
なるテンプレートエンジンを交換可能にする標準のような、フレームワークど
うしの互換性も生まれました。

WSGI の出現から Python の web フレームワークの世界は、 WSGI 標準に基づ
いた互換性に向かって進化していきました。 (最も複雑な web サイトを配置
するのに必要な全てのツールを提供する) "フルスタック" であれ、ミニマリ
ストであれ、その中間であれ、今や多くの web フレームワークが複数のフレ
ームワークで使える再利用可能なコンポーネントで構築されています。

大多数のユーザはおそらくコミュニティが活発な "フルスタック" フレームワ
ークを選びたいでしょう。 これらのフレームワークはきちんとドキュメント
が書かれ、機能を完全に揃えた web サイトを最小の時間で作る簡単な道が提
供されている傾向があります。


いくつかの注目に値するフレームワーク
------------------------------------

膨大な数のフレームワークがあるので、全てについて記述することは不可能で
す。 その代わりに最も人気のあるもののいくつかに簡単に触れます。


Django
~~~~~~

Django は、一から書かれた非常に上手く連携するいくつかの要素を固く結び
付けて構成されたフレームワークです。 Django には非常に強力でシンプルに
使える ORM があり、ブラウザでデータベースのデータを編集できる優れたオ
ンラインの管理インターフェースがあります。 テンプレートエンジンはテキ
ストベースで Python が書けないページデザイナーにも使えるよう設計されて
います。 このテンプレートエンジンはテンプレートの継承と (Unix のパイプ
のように動作する) フィルタをサポートしています。 Django には RSS フィ
ードや汎用ビュー (generic view) のようなたくさんの使いやすい機能が付属
しているため、 Python コードをほとんど書かずに web サイトを作ることが
できるようになっています。

Django には、多くの web サイトを作成してきたメンバーによる、大きな国際
的なコミュニティがあります。 Django の通常の機能を拡張するたくさんのア
ドオンプロジェクトもあります。 これらは Django の素晴しい オンラインド
キュメント と Django book による部分もあります。

注釈: Django は MVC スタイルのフレームワークですが、 Django は構成要
  素に対 して別の名前を付けています。 これについては Django FAQ で解説
  されて います。


TurboGears
~~~~~~~~~~

他の人気がある Python のフレームワークは TurboGears です。 TurboGears
は、既存のコンポーネントをグルーコードで組み合わせ、無理なく連携する使
い勝手を持たせるという手法をとっています。 TurboGeers にはユーザがコン
ポーネントを選べる柔軟性があります。 例えば、 ORM とテンプレートエンジ
ンはデフォルトとは異なるパッケージに変えられます。

ドキュメントが TurboGears documentation にあり、スクリーンキャストへの
リンクもあります。 TurboGears にも活発なユーザコミュニティがあり、関連
した質問のほとんどに答えてくれます。 入門に向いた TurboGears book も出
版されています。

TurboGears の最新版の version 2.0 では、よりいっそう WSGI サポートとコ
ンポーネントに基づくアーキテクチャに向けて進んでいます。 TurboGears 2
は Pylons というコンポーネントに基づく人気の web フレームワークの WSGI
スタックを基礎としています。


Zope
~~~~

Zope フレームワークは "古い原始の" フレームワークの1つです。 Zope2 の
現在の姿は、固く結合されたフルスタックなフレームワークです。 Zope の最
も興味深い機能の1つは、本体に固く結合されている ZODB (Zope Object
Database) と呼ばれる強力なオブジェクトデータベースです。 この固く結合
されている性質のために、 Zope はいくぶん孤立したエコシステムが形成され
ることとなりました: Zope 用に書かれたコードは Zope 以外の場所ではあま
り使えず、逆向きも同様です。 この問題を解決するために Zope 3 への取り
組みが始まりました。 Zope 3 では、より綺麗に分離されたコンポーネントの
集合体として Zope を再設計します。 この取り組みは WSGI 標準が考案され
るより前に始まりましたが、 Repoze プロジェクトによって Zope 3 のための
WSGI サポートが提供されています。 Zope のコンポーネントはそれまで何年
もプロダクションで使われていて、 Zope 3 プロジェクトではそれまでより広
い Python コミュニティに向けて、それらのコンポーネントが利用できるよう
になります。 Zope コンポーネントに基づく Zope とは別の Grok というフレ
ームワークさえあります。

Zope は Plone によって利用されているインフラストラクチャでもあります。
Plone は利用可能な中でもっとも強力で人気のあるコンテンツ管理システム
(content management system, CMS) の一つです。


他の注目に値するフレームワーク
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

もちろんこれらの二つだけが利用できるフレームワークの全てではありません
。 ここで触れておく価値のあるフレームワークは他にもたくさんあります。

既に述べた別のフレームワークに Pylons がありました。 Pylons は
TurboGears とよく似ていますが、柔軟性に磨きがかかっていて、利用するコ
ストが少々高くつきます。 ほぼ全ての要素は交換することができるため、個
々のコンポーネント全てについてドキュメントを利用する必要があり、そして
コンポーネントはたくさんあります。 Pylons は Paste という WSGI を扱い
やすい大量のツールの集合体に基づいて構築されています。

これで全てが述べられたわけではありません。最新の情報は Python wiki で
見つけることができます。

参考: Python wiki には広大な web フレームワーク のリストがあります。

  ほとんどのフレームワークは自身のメーリングリストや IRC チャンネルを
  持っているので、プロジェクトの web サイトからそれらを探して下さい。
