WebでPythonを使用する方法—Pythonドキュメント

提供：Dev Guides
< PythonPython/docs/2.7/howto/webservers
移動先:案内、検索

WebでPythonを使用する方法

著者
マレク・クビサ

概要

このドキュメントは、PythonがWebにどのように適合するかを示しています。 PythonをWebサーバーと統合するいくつかの方法と、Webサイトの開発に役立つ一般的な方法を紹介します。


Webサイトでユーザー生成コンテンツに焦点を当てた「Web2.0」の登場以来、Web向けプログラミングはホットな話題になっています。 Pythonを使用してWebサイトを作成することは常に可能でしたが、それはかなり退屈な作業でした。 そのため、開発者がより高速で堅牢なサイトを作成するのを支援するために、多くのフレームワークとヘルパーツールが作成されています。 このHOWTOでは、PythonをWebサーバーと組み合わせて動的コンテンツを作成するために使用されるいくつかの方法について説明します。 このトピックは広すぎて1つのドキュメントでカバーできないため、完全な紹介を意味するものではありません。 ただし、最も人気のあるライブラリの概要が提供されています。

も参照してください

このHOWTOはWebでPythonの概要を説明しようとしますが、常に希望どおりに最新であるとは限りません。 PythonでのWeb開発は急速に進んでいるため、 Webプログラミングのwikiページは最近の開発とより同期している可能性があります。


低レベルのビュー

ユーザーがWebサイトにアクセスすると、ブラウザーはサイトのWebサーバーに接続します（これは要求と呼ばれます）。 サーバーはファイルシステムでファイルを検索し、それをユーザーのブラウザーに送り返します。ブラウザーはそれを表示します（これは応答です）。 これは、基本的なプロトコルであるHTTPがどのように機能するかを大まかに示しています。

動的Webサイトは、ファイルシステム内のファイルではなく、要求が受信されたときにWebサーバーによって実行され、ユーザーに返されるコンテンツを生成するプログラムに基づいています。 掲示板の投稿を表示したり、メールを表示したり、ソフトウェアを設定したり、現在の時刻を表示したりするなど、あらゆる種類の便利な機能を実行できます。 これらのプログラムは、サーバーがサポートする任意のプログラミング言語で作成できます。 ほとんどのサーバーはPythonをサポートしているため、Pythonを使用して動的なWebサイトを作成するのは簡単です。

ほとんどのHTTPサーバーはCまたはC ++で記述されているため、Pythonコードを直接実行することはできません。サーバーとプログラムの間にブリッジが必要です。 これらのブリッジ、つまりインターフェイスは、プログラムがサーバーと対話する方法を定義します。 可能な限り最高のインターフェースを作成するための多くの試みがありましたが、言及する価値のあるものはほんのわずかです。

すべてのWebサーバーがすべてのインターフェイスをサポートしているわけではありません。 多くのWebサーバーは、古い、現在は廃止されたインターフェースのみをサポートしています。 ただし、多くの場合、サードパーティのモジュールを使用して拡張し、新しいモジュールをサポートできます。

Common Gateway Interface

このインターフェイスは、最も一般的に「CGI」と呼ばれ、最も古く、ほとんどすべてのWebサーバーですぐにサポートされます。 CGIを使用してWebサーバーと通信するプログラムは、要求ごとにサーバーによって開始される必要があります。 そのため、すべてのリクエストで新しいPythonインタープリターが開始され（起動に時間がかかります）、インターフェイス全体が低負荷の状況でのみ使用できるようになります。

CGIの利点は、それが単純なことです。CGIを使用するPythonプログラムの作成は、約3行のコードの問題です。 この単純さには代償が伴います。開発者を支援することはほとんどありません。

CGIプログラムを作成することは可能ですが、推奨されなくなりました。 このドキュメントで後述するトピックである WSGI を使用すると、CGIをエミュレートするプログラムを作成できるため、より適切なオプションがない場合でもCGIとして実行できます。

も参照してください

Python標準ライブラリには、プレーンCGIプログラムの作成に役立ついくつかのモジュールが含まれています。

  • cgi –CGIスクリプトでのユーザー入力の処理
  • cgitb –「500Internal Server Error」メッセージを表示する代わりに、CGIアプリケーションでエラーが発生したときに優れたトレースバックを表示します

Python wikiには、 CGIスクリプトのページとPythonのCGIに関する追加情報が掲載されています。


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

WebサーバーがCGIで動作するかどうかをテストするには、次の短くて単純な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ラインとは何か疑問に思われるかもしれません。 この行により、ユーザーのブラウザで単にクラッシュして「内部サーバーエラー」を表示する代わりに、優れたトレースバックを表示することができます。 これはデバッグには役立ちますが、機密データをユーザーに公開するリスクがあります。 このため、本番コードではcgitbを使用しないでください。 常に例外をキャッチし、適切なエラーページを表示する必要があります。エンドユーザーは、ブラウザにわかりにくい「内部サーバーエラー」が表示されることを好みません。


独自のサーバーでCGIを設定する

独自のWebサーバーがない場合、これは適用されません。 そのまま動作するかどうかを確認できます。動作しない場合は、Webサーバーの管理者に相談する必要があります。 大きなホストの場合は、Pythonサポートを求めるチケットを提出してみてください。

自分の管理者である場合、または自分のコンピューターでテスト目的でCGIをセットアップする場合は、自分で構成する必要があります。 さまざまな構成オプションを持つ多くのWebサーバーがあるため、CGIを構成する単一の方法はありません。 現在最も広く使用されている無料のWebサーバーは、 Apache HTTPd 、または略してApacheです。 Apacheは、システムのパッケージ管理ツールを使用して、ほぼすべてのシステムに簡単にインストールできます。 lighttpd は別の選択肢であり、パフォーマンスが優れていると言われています。 多くのシステムでは、このサーバーはパッケージ管理ツールを使用してインストールすることもできるため、Webサーバーを手動でコンパイルする必要がない場合があります。

  • Apacheでは、 Dynamic Content with CGI チュートリアルを見ることができます。ここでは、すべてが説明されています。 ほとんどの場合、+ExecCGIを設定するだけで十分です。 チュートリアルでは、発生する可能性のある最も一般的な落とし穴についても説明します。
  • lighttpdでは、 CGIモジュールを使用する必要があります。これは簡単な方法で構成できます。 つまり、cgi.assignを正しく設定することになります。


CGIスクリプトに関する一般的な問題

CGIを使用すると、これらのスクリプトを実行しようとしているときに、小さな煩わしさが生じることがあります。 一見正しいスクリプトが期待どおりに機能しない場合があります。原因は、特定が難しい小さな隠れた問題です。

これらの潜在的な問題のいくつかは次のとおりです。

  • Pythonスクリプトは実行可能としてマークされていません。 CGIスクリプトが実行可能でない場合、ほとんどのWebサーバーは、スクリプトを実行してユーザーに出力を送信する代わりに、ユーザーがスクリプトをダウンロードできるようにします。 CGIスクリプトをUnixライクなオペレーティングシステムで正しく実行するには、+xビットを設定する必要があります。 chmod a+x your_script.pyを使用すると、この問題を解決できる場合があります。
  • Unixライクなシステムでは、プログラムファイルの行末はUnixスタイルの行末である必要があります。 Webサーバーはスクリプトの最初の行（shebangと呼ばれる）をチェックし、そこで指定されたプログラムを実行しようとするため、これは重要です。 Windowsの行末（キャリッジリターンとラインフィード、CRLFとも呼ばれます）によって混乱しやすいため、ファイルをUnixの行末（ラインフィード、LFのみ）に変換する必要があります。 これは、バイナリモードではなくテキストモードでFTP経由でファイルをアップロードすることで自動的に実行できますが、推奨される方法は、Unixの行末でファイルを保存するようにエディターに指示することです。 ほとんどの編集者はこれをサポートしています。
  • Webサーバーがファイルを読み取れる必要があり、アクセス許可が正しいことを確認する必要があります。 UNIXライクなシステムでは、サーバーはユーザーおよびグループwww-dataとして実行されることが多いため、ファイルの所有権を変更するか、chmod a+r your_script.pyを使用してファイルを読み取り可能にすることをお勧めします。
  • Webサーバーは、アクセスしようとしているファイルがCGIスクリプトであることを認識している必要があります。 CGIスクリプトの特定のファイル拡張子を期待するように構成されている可能性があるため、Webサーバーの構成を確認してください。
  • Unixライクなシステムでは、シバン（#!/usr/bin/env python）のインタプリタへのパスが正しい必要があります。 この行は/usr/bin/envを呼び出してPythonを検索しますが、/usr/bin/envがない場合、またはPythonがWebサーバーのパスにない場合は失敗します。 Pythonがインストールされている場所がわかっている場合は、そのフルパスを使用することもできます。 コマンドwhereis pythonおよびtype -p pythonは、インストールされている場所を見つけるのに役立ちます。 パスがわかったら、それに応じてシェバンを変更できます：#!/usr/bin/python。
  • ファイルにはBOM（バイトオーダーマーク）が含まれていてはなりません。 BOMは、UTF-16およびUTF-32エンコーディングのバイト順序を決定するためのものですが、一部のエディターはこれをUTF-8ファイルにも書き込みます。 BOMはシバンラインに干渉するため、BOMを作成しないようにエディターに指示してください。
  • Webサーバーが mod_python を使用している場合は、mod_pythonに問題がある可能性があります。 mod_pythonはそれ自体でCGIスクリプトを処理できますが、問題の原因になることもあります。


mod_python

PHPを使用している人は、WebでPythonを使用する方法を理解するのが難しいと感じることがよくあります。 彼らが最初に考えたのは、ほとんどが mod_python です。これは、mod_phpと同等であると考えているためです。 実際には、多くの違いがあります。 mod_pythonが行うことは、インタープリターをApacheプロセスに埋め込むことです。これにより、リクエストごとにPythonインタープリターを起動する必要がなくなり、リクエストが高速化されます。 一方、PHPがHTMLと混ざり合うことが多いように、「PythonとHTMLが混ざり合っている」わけではありません。 これに相当するPythonはテンプレートエンジンです。 mod_python自体ははるかに強力であり、Apache内部へのより多くのアクセスを提供します。 CGIをエミュレートし、「HTMLとPythonが混在する」「PythonServer Pages」モード（JSPと同様）で動作し、1つのファイルを指定してすべてのリクエストを受け入れ、それらをどう処理するかを決定する「パブリッシャー」を備えています。 。

mod_pythonにはいくつかの問題があります。 PHPインタープリターとは異なり、Pythonインタープリターはファイルの実行時にキャッシュを使用するため、ファイルを変更するにはWebサーバーを再起動する必要があります。 もう1つの問題は、基本的な概念です。Apacheは、要求を処理するために子プロセスを開始します。残念ながら、すべての子プロセスは、Pythonインタープリターを使用しない場合でも、Pythonインタープリター全体をロードする必要があります。 これにより、Webサーバー全体の速度が低下します。 もう1つの問題は、mod_pythonがlibpythonの特定のバージョンに対してリンクされているため、古いバージョンから新しいバージョンに切り替えることができないことです（例： 2.4から2.5）mod_pythonを再コンパイルせずに。 mod_pythonもApacheWebサーバーにバインドされているため、mod_python用に作成されたプログラムを他のWebサーバーで簡単に実行することはできません。

これらが、新しいプログラムを書くときにmod_pythonを避けるべき理由です。 状況によっては、展開にmod_pythonを使用することをお勧めしますが、WSGIを使用すると、mod_pythonでWSGIプログラムを実行することもできます。


FastCGIとSCGI

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

SCGIは本質的に単なる「より単純なFastCGI」であるため、FastCGIとSCGIの違いは非常に小さいです。 SCGIのWebサーバーのサポートは制限されているため、ほとんどの人は代わりにFastCGIを使用します。これは同じように機能します。 SCGIに適用されるほとんどすべてがFastCGIにも適用されるため、後者についてのみ説明します。

最近では、FastCGIが直接使用されることはありません。 mod_pythonと同様に、WSGIアプリケーションの展開にのみ使用されます。

FastCGIの設定

各Webサーバーには特定のモジュールが必要です。

  • Apacheには、 mod_fastcgi と mod_fcgid の両方があります。 mod_fastcgiはオリジナルのものですが、ライセンスの問題がいくつかあるため、無料ではないと見なされることがあります。 mod_fcgidは、より小さく、互換性のある代替手段です。 これらのモジュールの1つは、Apacheによってロードされる必要があります。
  • lighttpdには、独自の FastCGIモジュールと SCGIモジュールが付属しています。
  • 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()

これは単純なWSGIアプリケーションですが、flupが低レベルのFastCGIアクセスを処理するため、最初に flup をインストールする必要があります。

も参照してください

WSGIを使用したDjangoのセットアップに関するドキュメントがいくつかあり、そのほとんどは他のWSGI準拠のフレームワークやライブラリに再利用できます。 manage.pyパーツのみを変更する必要があり、代わりにここで使用されている例を使用できます。 Djangoは多かれ少なかれまったく同じことをします。


mod_wsgi

mod_wsgi は、低レベルのゲートウェイを取り除く試みです。 FastCGI、SCGI、およびmod_pythonが主にWSGIアプリケーションのデプロイに使用されることを考えると、mod_wsgiは、WSGIアプリケーションをApacheWebサーバーに直接埋め込むために開始されました。 mod_wsgiは、WSGIアプリケーションをホストするように特別に設計されています。 これにより、グルーコードを必要とする他の低レベルの方法を使用した展開よりも、WSGIアプリケーションの展開がはるかに簡単になります。 欠点は、mod_wsgiがApacheWebサーバーに制限されていることです。 他のサーバーには、mod_wsgiの独自の実装が必要です。

mod_wsgiは、Apacheプロセスと統合する組み込みモードとFastCGIに似たデーモンモードの2つのモードをサポートします。 FastCGIとは異なり、mod_wsgiはワーカープロセスを単独で処理するため、管理が容易になります。


ステップバック：WSGI

WSGIはすでに何度か言及されているため、重要なものでなければなりません。 実際、それは本当にそうです、そして今それを説明する時が来ました。

Webサーバーゲートウェイインターフェイス、または略してWSGIは、 PEP 333 で定義されており、現在PythonWebプログラミングを行うための最良の方法です。 フレームワークを作成するプログラマーにとっては素晴らしいことですが、通常のWeb開発者はフレームワークに直接触れる必要はありません。 Web開発用のフレームワークを選択するときは、WSGIをサポートするフレームワークを選択することをお勧めします。

WSGIの大きな利点は、アプリケーションプログラミングインターフェイスの統合です。 プログラムがWSGIと互換性がある場合（外部レベルでは、使用しているフレームワークがWSGIをサポートしていることを意味します）、プログラムはWSGIラッパーが存在する任意のWebサーバーインターフェイスを介して展開できます。 アプリケーションユーザーがmod_python、FastCGI、またはmod_wsgiのいずれを使用するかを気にする必要はありません。WSGIを使用すると、アプリケーションは任意のゲートウェイインターフェイスで動作します。 Python標準ライブラリには、独自のWSGIサーバー wsgiref が含まれています。これは、テストに使用できる小さなWebサーバーです。

本当に素晴らしいWSGI機能はミドルウェアです。 ミドルウェアは、プログラムにさまざまな機能を追加できるプログラムの周りのレイヤーです。 すでにかなりの数のミドルウェアが利用可能です。 たとえば、独自のセッション管理を作成する代わりに（HTTPはステートレスプロトコルであるため、複数のHTTPリクエストを単一のユーザーに関連付けるには、アプリケーションがセッションを介してそのような状態を作成および管理する必要があります）、それを実行するミドルウェアをダウンロードするだけで、プラグインできます。それを取り入れて、アプリケーションの固有の部分のコーディングに取り掛かります。 圧縮についても同じことが言えます。サーバーの帯域幅を節約するためにgzipを使用してHTMLの圧縮を処理する既存のミドルウェアがあります。 認証は、既存のミドルウェアを使用して簡単に解決できるもう1つの問題です。

WSGIは複雑に見えるかもしれませんが、WSGIと関連するミドルウェアには、Webサイトの開発中に発生する可能性のある多くの問題に対する解決策がすでにあるため、学習の初期段階は非常にやりがいがあります。

WSGIサーバー

CGIやmod_pythonなどのさまざまな低レベルゲートウェイに接続するために使用されるコードは、 WSGIサーバーと呼ばれます。 これらのサーバーの1つは、FastCGIとSCGI、および AJP をサポートするflupです。 flupのように、これらのサーバーの一部はPythonで記述されていますが、Cで記述され、ドロップインの代替として使用できるサーバーもあります。

すでに多くのサーバーが利用可能であるため、PythonWebアプリケーションはほぼどこにでもデプロイできます。 これは、Pythonが他のWebテクノロジーと比較した大きな利点の1つです。

も参照してください

WSGI関連のコードの概要は、 WSGIホームページにあります。このホームページには、任意のアプリケーションがサポートする WSGIサーバーの広範なリストが含まれています。 WSGI。

標準ライブラリにすでに含まれているいくつかのWSGIサポートモジュールに興味があるかもしれません。

  • wsgiref –WSGI用のいくつかの小さなユーティリティとサーバー


ケーススタディ：MoinMoin

WSGIはWebアプリケーション開発者に何を提供しますか？ WSGIを使用せずにPythonで記述された、しばらく前から存在しているアプリケーションを見てみましょう。

最も広く使用されているウィキソフトウェアパッケージの1つは、 MoinMoin です。 2000年に作成されたため、WSGIより約3年前のものです。 古いバージョンでは、CGI、mod_python、FastCGI、およびスタンドアロンで実行するために個別のコードが必要でした。

WSGIのサポートが含まれるようになりました。 WSGIを使用すると、追加のグルーコードなしで、WSGI準拠のサーバーにMoinMoinをデプロイできます。 WSGI以前のバージョンとは異なり、これにはMoinMoinの作成者が何も知らないWSGIサーバーが含まれる可能性があります。


Model-View-Controller

MVC という用語は、「フレームワーク foo はMVCをサポートしています」などのステートメントでよく使用されます。 MVCは、特定のAPIではなく、コードの全体的な編成に関するものです。 多くのWebフレームワークは、このモデルを使用して、開発者がプログラムに構造をもたらすのを支援します。 より大きなWebアプリケーションには多くのコードが含まれる可能性があるため、最初から効果的な構造を用意することをお勧めします。 そうすれば、他のフレームワーク（または、MVCはPython固有ではないため、他の言語）のユーザーでも、MVC構造に既に精通していれば、コードを簡単に理解できます。

MVCは、次の3つのコンポーネントを表します。

  • モデル。 これは、表示および変更されるデータです。 Pythonフレームワークでは、このコンポーネントは、オブジェクトリレーショナルマッパーによって使用されるクラスによって表されることがよくあります。
  • ビュー。 このコンポーネントの仕事は、モデルのデータをユーザーに表示することです。 通常、このコンポーネントはテンプレートを介して実装されます。
  • コントローラー。 これは、ユーザーとモデルの間のレイヤーです。 コントローラは、ユーザーのアクション（特定のURLを開くなど）に反応し、必要に応じてデータを変更するようにモデルに指示し、表示する内容をビューコードに指示します。

MVCは複雑なデザインパターンであると思われるかもしれませんが、実際はそうではありません。 クリーンで保守しやすいWebサイトを作成するのに役立つことがわかったため、Pythonで使用されています。

ノート

すべてのPythonフレームワークがMVCを明示的にサポートしているわけではありませんが、データロジック（モデル）をユーザーインタラクションロジック（コントローラー）およびテンプレート（ビュー）から分離することにより、MVCパターンを使用するWebサイトを作成するのは簡単です。 そのため、テンプレートに不要なPythonコードを記述しないことが重要です。これは、MVCモデルに対して機能し、コードベースに混乱を引き起こし、理解と変更を困難にします。


も参照してください

英語版ウィキペディアには、 Model-View-Controllerパターンに関する記事があります。 さまざまなプログラミング言語用の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で利用可能なテンプレートエンジンがたくさんあります。 これらのいくつかは、範囲が限られていることもあり、習得が容易なプレーンテキストプログラミング言語を定義しています。 その他はXMLを使用し、テンプレート出力は常に有効なXMLであることが保証されています。 他にも多くのバリエーションがあります。

一部のフレームワークは、独自のテンプレートエンジンを出荷するか、特に1つを推奨します。 別のテンプレートエンジンを使用する理由がない場合は、フレームワークによって提供または推奨されているものを使用することをお勧めします。

人気のあるテンプレートエンジンは次のとおりです。

も参照してください

Pythonで作成するのは非常に簡単なので、注目を集めるために競合する多くのテンプレートエンジンがあります。 ウィキのページテンプレートには、これらの数が増え続けています。 上記の3つは、「第2世代」のテンプレートエンジンと見なされており、開始するのに適しています。


データの永続性

データの永続性は非常に複雑に聞こえますが、データを保存するだけです。 このデータは、ブログエントリのテキスト、掲示板への投稿、またはWikiページのテキストである可能性があります。 もちろん、Webサーバーに情報を保存する方法はいくつかあります。

多くの場合、 MySQL や PostgreSQL などのリレーショナルデータベースエンジンは、数百万のエントリで構成される非常に大規模なデータベースを処理する際のパフォーマンスが優れているために使用されます。 SQLite と呼ばれる小さなデータベースエンジンもあります。これは、 sqlite3 モジュールでPythonにバンドルされており、1つのファイルのみを使用します。 他の依存関係はありません。 小規模なサイトの場合、SQLiteで十分です。

リレーショナルデータベースは、 SQL と呼ばれる言語を使用してクエリされます。 Pythonプログラマーは一般に、オブジェクトを操作することを好むため、SQLをあまり好きではありません。 ORM （オブジェクトリレーショナルマッピング）と呼ばれるテクノロジを使用して、Pythonオブジェクトをデータベースに保存することができます。 ORMは、すべてのオブジェクト指向アクセスを内部でSQLコードに変換するため、開発者はそれについて考える必要はありません。 ほとんどのフレームワークはORMを使用しており、非常にうまく機能します。

2番目の可能性は、データを通常のプレーンテキストファイル（「フラットファイル」と呼ばれることもあります）に保存することです。 これは単純なサイトでは非常に簡単ですが、Webサイトが保存されたデータに対して多くの更新を実行している場合は正しく理解するのが難しい場合があります。

3番目の可能性は、オブジェクト指向データベース（「オブジェクトデータベース」とも呼ばれます）です。 これらのデータベースは、プログラムの実行中にオブジェクトがメモリ内で構造化される方法とほぼ同じ形式でオブジェクトデータを格納します。 （対照的に、ORMはオブジェクトデータをテーブル内のデータの行およびそれらの行間の関係として格納します。）オブジェクトを直接格納することには、一部のオブジェクトが非常に多いリレーショナルデータベースとは異なり、ほぼすべてのオブジェクトを簡単な方法で保存できるという利点があります。表現するのは難しい。

Frameworks は、多くの場合、どのデータストレージ方法を選択するかについてのヒントを提供します。 アプリケーションに代替ストレージメカニズムによってより適切に満たされる特別な要件がない限り、通常はフレームワークが推奨するデータストアに固執することをお勧めします。

も参照してください

  • 永続化ツールには、ファイルシステムにデータを保存する方法の可能性がリストされています。 これらのモジュールのいくつかは、標準ライブラリの一部です
  • データベースプログラミングは、データの保存方法の選択に役立ちます
  • Python用の最も強力なORマッパーである SQLAlchemy 、およびSQLAlchemyを使いやすくする Elixir
  • SQLObject 、もう1つの人気のあるORマッパー
  • ZODB および Durus 、2つのオブジェクト指向データベース


フレームワーク

Webサイトを実行するためのコードを作成するプロセスには、さまざまなサービスを提供するためのコードの記述が含まれます。 特定のサービスを提供するコードは、問題のWebサイトの複雑さや目的に関係なく、同じように機能することがよくあります。 これらの一般的なソリューションを再利用可能なコードに抽象化すると、Web開発用の「フレームワーク」と呼ばれるものが生成されます。 おそらく、Web開発で最もよく知られているフレームワークはRuby on Railsですが、Pythonには独自のフレームワークがあります。 これらのいくつかは、部分的にRailsに触発されたか、Railsからアイデアを借りましたが、多くはRailsよりずっと前から存在していました。

もともとPythonWebフレームワークは、Webサイトを巨大な統合ツールセットとして開発するために必要なすべてのサービスを組み込む傾向がありました。 2つのWebフレームワークは相互運用可能ではありませんでした。1つのために開発されたプログラムは、かなりのリエンジニアリング作業なしに別のフレームワークに展開することはできませんでした。 これにより、Pythonコードとhttpプロトコルの間で通信するためのツールのみを提供する「ミニマリスト」Webフレームワークが開発され、他のすべてのサービスは個別のコンポーネントを介して追加されました。 異なるテンプレートエンジンを交換可能に使用できるようにする標準など、フレームワーク間の相互運用性を制限できるいくつかのアドホック標準が開発されました。

WSGIの登場以来、Python Webフレームワークの世界は、WSGI標準に基づく相互運用性に向けて進化してきました。 現在、多くのWebフレームワークは、「フルスタック」（最も複雑なWebサイトを展開するために必要なすべてのツールを提供）、ミニマリスト、またはその間のものにかかわらず、複数のフレームワークで使用できる再利用可能なコンポーネントのコレクションから構築されています。

大多数のユーザーは、アクティブなコミュニティを持つ「フルスタック」フレームワークを選択したいと思うでしょう。 これらのフレームワークは十分に文書化されている傾向があり、最小限の時間で完全に機能するWebサイトを作成するための最も簡単な方法を提供します。

いくつかの注目すべきフレームワーク

フレームワークの数は非常に多いため、ここですべてを網羅することはできません。 代わりに、最も人気のあるもののいくつかに簡単に触れます。

Django

Django は、ゼロから作成され、非常にうまく連携するいくつかの緊密に結合された要素で構成されるフレームワークです。 非常に強力でありながら使いやすく、ブラウザでデータベース内のデータを編集できる優れたオンライン管理インターフェイスを備えたORMが含まれています。 テンプレートエンジンはテキストベースであり、Pythonを記述できないページデザイナーが使用できるように設計されています。 テンプレートの継承とフィルター（Unixパイプのように機能します）をサポートします。 Djangoには、RSSフィードや汎用ビューの作成など、多くの便利な機能がバンドルされており、Pythonコードをほとんど記述せずにWebサイトを作成できます。

そこには大きな国際的なコミュニティがあり、そのメンバーは多くのWebサイトを作成しています。 Djangoの通常の機能を拡張するアドオンプロジェクトもたくさんあります。 これは、Djangoのよく書かれたオンラインドキュメントと Djangoブックが原因の1つです。

ノート

DjangoはMVCスタイルのフレームワークですが、要素の名前が異なります。これについては、 Django FAQ で説明されています。


TurboGears

Python用のもう1つの人気のあるWebフレームワークは、 TurboGears です。 TurboGearsは、既存のコンポーネントを使用し、それらをグルーコードと組み合わせてシームレスなエクスペリエンスを作成するというアプローチを採用しています。 TurboGearsは、ユーザーがコンポーネントを柔軟に選択できるようにします。 たとえば、ORMとテンプレートエンジンは、デフォルトで使用されているものとは異なるパッケージを使用するように変更できます。

ドキュメントは TurboGearsドキュメントにあり、スクリーンキャストへのリンクがあります。 TurboGearsには、関連するほとんどの質問に回答できるアクティブなユーザーコミュニティもあります。 TurboGearsの本も出版されており、これは良い出発点です。

TurboGearsの最新バージョンであるバージョン2.0は、WSGIサポートとコンポーネントベースのアーキテクチャの方向にさらに進んでいます。 TurboGears 2は、別の人気のあるコンポーネントベースのWebフレームワーク Pylons のWSGIスタックに基づいています。


Zope

Zopeフレームワークは、「古いオリジナル」フレームワークの1つです。 Zope2での現在の化身は、緊密に統合されたフルスタックフレームワークです。 その最も興味深い機能の1つは、 ZODB （Zope Object Database）と呼ばれる強力なオブジェクトデータベースとの緊密な統合です。 高度に統合された性質のため、Zopeはやや孤立したエコシステムになりました。Zope用に記述されたコードはZopeの外部ではあまり使用できず、その逆も同様でした。 この問題を解決するために、Zope3の取り組みが開始されました。 Zope 3は、よりクリーンに分離されたコンポーネントのセットとしてZopeを再設計します。 この取り組みはWSGI標準が登場する前に開始されましたが、 Repoze プロジェクトからZope3のWSGIサポートがあります。 Zopeコンポーネントは、その背後で長年の実稼働で使用されており、Zope 3プロジェクトは、これらのコンポーネントへのアクセスをより広いPythonコミュニティに提供します。 Zopeコンポーネントに基づく別のフレームワーク Grok もあります。

Zopeは、 Plone コンテンツ管理システムで使用されるインフラストラクチャでもあります。これは、利用可能な最も強力で人気のあるコンテンツ管理システムの1つです。


その他の注目すべきフレームワーク

もちろん、利用できるフレームワークはこれらだけではありません。 言及する価値のある他の多くのフレームワークがあります。

すでに言及されているもう1つのフレームワークは、 Pylons です。 PylonsはTurboGearsによく似ていますが、柔軟性がさらに重視されているため、使用が難しくなります。 ほぼすべてのコンポーネントを交換できるため、多くのコンポーネントがあるすべてのコンポーネントのドキュメントを使用する必要があります。 Pylonsは、WSGIに便利なツールの広範なセットである Paste に基づいて構築されています。

そして、それはまだすべてではありません。 最新の情報は常にPythonwikiにあります。

も参照してください

Python wikiには、 Webフレームワークの広範なリストが含まれています。

ほとんどのフレームワークには独自のメーリングリストとIRCチャネルもあります。これらについては、プロジェクトのWebサイトで確認してください。



「https://www.finddevguides.com/index.php?title=Python/docs/2.7/howto/webservers&oldid=97036」から取得
Powered by MediaWiki