PEP(Python Enhancement Proposal)はPythonを改良する案、リリーススケジュール、コーディングスタイルなど開発を円滑に進める上で重要なことを文書にまとめておく場所。ここには、Pythonをコーディングするすべての人にとって重要な内容がきっと入っているはず。ビギナーが言うようにもちろん、英語。よって、これをできるだけ毎日、翻訳しながら読み解きまとめていくことで備忘録としていきたいと思います。英語は非常に苦手なので誤訳はご指摘ください。
※以下、アイコンが出てくる箇所は私のコメントになります。それ以外は、翻訳または翻訳のまとめです。
Contents
基本情報
Web Library Enhancements
PEP: | 222 | |
---|---|---|
Title: | Web Library Enhancements | |
Web ライブラリの拡張 | ||
Author: | A.M. Kuchling <amk at amk.ca> | |
Status: | Deferred | |
Type: | Standards Track | |
Created: | 18-Aug-2000 | |
Python-Version: | 2.1 | |
Post-History: | 22-Dec-2000 |
アブストラクト
このPEPは、Python標準ライブラリのCGI開発機能に対する一連の機能強化を提案しています。機能強化は、新機能、Cookieサポートなどのタスク用の新しいモジュール、または廃止されたコードの削除などです。
当初の目的はPython 2.1を改良することでした。しかし、Pythonコミュニティからはほとんど関心がなく、時間が足りなかったため、このPEPは将来のPythonリリースまで延期されました。
未解決の問題
このセクションでは、提案されている変更をリストしていますが、まだ確定的な決定は行われていません。このPEPの最終版では、すべての変更が承認済みまたはリジェクト済みとして分類されるため、このセクションは空にする必要があります。
cgi.py
:ファイルのアップロードを処理できるように、独自のサブクラスを作成するように指示されるべきではありません。これを正しく実行する機会をまだ見つけていないので、cgi.py
の一時ファイルを別のファイルに読み込むことになります。当社のレガシーコードの中には、実際に2番目の一時ファイルに読み込んでから、最終的な保存先に読み込むものがあります。たとえ行ったとしても、その__init__
呼び出しとそれに関連したオーバーヘッドでさらに別のオブジェクトを作成することを意味します。
cgi.py
:現在のところ、no =
を持つクエリデータは無視されます。 keep_blank_values
が設定されていても、...?value=&...
のようなクエリは空白の値で返されますが、...?value&...
のようなクエリは完全に失われます。そのようなデータが、値としてNone
を持つエントリとして、または別のリストとして、FieldStorage
インタフェースを通して利用可能にすればよいでしょう。
ユーティリティ関数:2タプルのリストから問い合わせ文字列を作る
辞書関連のユーティリティクラス:NoKeyErrors
(空の文字列を返し、KeyError
は返しません)、PartialStringSubstitution
(元のキー文字列を返します、KeyError
は返しません)
新しいモジュール
このセクションでは、Python標準ライブラリに追加されるべき全ての新しいパッケージやモジュールについての詳細をリストします。
fcgi.py
FastCGIプロトコルのサポートを追加した新しいモジュール。ただし、Robin DunnのコードはWindowsに移植する必要があります。
既存モジュールの主な変更点
このセクションでは、インプリメンテーションであれインターフェースであれ、既存のモジュールに対する主な変更点の詳細をリストします。したがって、このセクションの変更は、バグの導入または下位互換性のいずれかにおいて、より大きなリスクを伴います。
cgi.py
モジュールは廃止予定です。(新しいモジュールまたはパッケージ名はまだ選択されていません:’web
‘? ‘cgilib
‘?)
既存モジュールのマイナーチェンジ
このセクションでは、既存のモジュールに対する小さな変更の詳細をリストします。これらの変更は比較的小さな実装を持つべきであり、以前のバージョンとの非互換性をもたらす危険性はほとんどありません。
リジェクトされた変更点
このセクションに記載されている変更はPython2.1用に提案されたものですが、不適切として拒否されました。拒否された変更ごとに、その変更が不適切と見なされた理由を説明する論理的根拠が示されます。
HTML
生成モジュールはこのPEPの一部ではありませんHTMLgenの純粋なプログラミングインターフェースからASP風のシンプルなテンプレート作成、DTMLの複雑なテンプレート作成まで、そのようなモジュールがいくつか存在します。 どのテンプレートモジュールを標準ライブラリで保護するべきかについての指示はなく、それはおそらくそのように選択されるべきモジュールがないことを意味します。cgi.py
クエリデータとPOSTデータの組み合わせを許可します。標準的なことではないため、疑わしい方法です。
提案されたインターフェース
未解決問題:命名規則(スタッドキャップまたは下線区切り?)。 cgi.parse *()
関数を見て、それらも単純化できるかどうかを調べる必要があります。
構文解析関数:cgi.py
のほとんどのparse *
関数を継承します。
# The Response class borrows most of its methods from Zope's # HTTPResponse class. class Response: """ Attributes: status: HTTP status code to return headers: dictionary of response headers body: string containing the body of the HTTP response """ def __init__(self, status=200, headers={}, body=""): pass def setStatus(self, status, reason=None): "Set the numeric HTTP response code" pass def setHeader(self, name, value): "Set an HTTP header" pass def setBody(self, body): "Set the body of the response" pass def setCookie(self, name, value, path = '/', comment = None, domain = None, max-age = None, expires = None, secure = 0 ): "Set a cookie" pass def expireCookie(self, name): "Remove a cookie from the user" pass def redirect(self, url): "Redirect the browser to another URL" pass def __str__(self): "Convert entire response to a string" pass def dump(self): "Return a string representation useful for debugging" pass # XXX methods for specific classes of error:serverError, # badRequest, etc.? class Request: """ Attributes: XXX should these be dictionaries, or dictionary-like objects? .headers : dictionary containing HTTP headers .cookies : dictionary of cookies .fields : data from the form .env : environment dictionary """ def __init__(self, environ=os.environ, stdin=sys.stdin, keep_blank_values=1, strict_parsing=0): """Initialize the request object, using the provided environment and standard input.""" pass # Should people just use the dictionaries directly? def getHeader(self, name, default=None): pass def getCookie(self, name, default=None): pass def getField(self, name, default=None): "Return field's value as a string (even if it's an uploaded file)" pass def getUploadedFile(self, name): """Returns a file object that can be read to obtain the contents of an uploaded file. XXX should this report an error if the field isn't actually an uploaded file? Or should it wrap a StringIO around simple fields for consistency? """ def getURL(self, n=0, query_string=0): """Return the URL of the current request, chopping off 'n' path components from the right. Eg. if the URL is "http://foo.com/bar/baz/quux", n=2 would return "http://foo.com/bar". Does not include the query string (if any) """ def getBaseURL(self, n=0): """Return the base URL of the current request, adding 'n' path components to the end to recreate more of the whole URL. Eg. if the request URL is "http://foo.com/q/bar/baz/qux", n=0 would return "http://foo.com/", and n=2 "http://foo.com/q/bar". Returned URL does not include the query string, if any. """ def dump(self): "String representation suitable for debugging output" pass # Possibilities? I don't know if these are worth doing in the # basic objects. def getBrowser(self): "Returns Mozilla/IE/Lynx/Opera/whatever" def isSecure(self): "Return true if this is an SSLified request" # Module-level function def wrapper(func, logfile=sys.stderr): """ Calls the function 'func', passing it the arguments (request, response, logfile). Exceptions are trapped and sent to the file 'logfile'. """ # This wrapper will detect if it's being called from the command-line, # and if so, it will run in a debugging mode; name=value pairs # can be entered on standard input to set field values. # (XXX how to do file uploads in this syntax?)