flask

werkzeugとjinja2を活用したフレームワーク。
マイクロフレームワーク。外部ライブラリを除けばビュー周りしかサポートしていない。

スレッドローカルなオブジェクトたち

werkzeug.localを使ってrequest等をグローバルオブジェクトに見立てる。
→これはどこからでもアクセスできるようにするためか？当然実装コードは複雑化している。

？LocalProxyがスレッドセーフであることはどうやって確保されている？
→thread.get_ident or gleenlet.get_current関数で得られるidをキーに、Localオブジェクトがデータを管理しているので、同じキーの更新は複数スレッドから起こらないということ。

コンテキスト

各種コンテキストオブジェクトはグローバルな形式でアクセスできるようになっている。

セッション

werkzeugのセッションモジュールは全く使っていない。
SessionInterfaceとSessionCookieSessionがキー。SessionInterfaceがセッションの生成や保存等の操作を担い、SessionCookieがセッション情報を持つ。
セッションはRequestContextに保持される。

操作とデータが分離しているので、一見反オブジェクト指向な感じがするが、sessions.pyというひとつのモジュールとして捉えればそうでもないのだろう。

コンフィグレーション

app.configオブジェクトを通してConfigインスタンスにアクセスする。
コンフィグオブジェクトはdictのサブクラスであるため、flask側で設定していない値も設定可能。
ConfigAttributeをアプリケーションオブジェクトに設定することで、アプリケーションオブジェクトから一部の設定値にアクセスすることが可能。ConfigAttributeはコンフィグインスタンスへの仲介をしているだけ。ちょっと必要性は疑わしい。

戻り値

戻り値をrvと表記する緩いルールがあるよう。処理が長い関数では何が戻り値なのかわかりやすく良い反面、rvという名前に戻り値であること以外の情報はないため、どのような値が返るのか最初に明示しないと可読性を下げる。

ビュー

render_templateやjsonifyなど、フォーマットに応じたビュー関数。

ブループリント

アプリケーションの操作を拡張できる機能。ベースとなるアプリケーションを作ったり、大きなアプリケーションをURLルートごとに複数に分割することが可能となる。

wtforms

flaskで紹介されているバリデーションフレームワーク。

パラメータデータコンバートとバリデーション

データコンバートはFormインスタンス生成時（process）、バリデーションはvalidateメソッド実行時に行っているが、データコンバートでエラーがでてもエラー情報を保持しておくだけで例外は伝播させない。validate実行時にマージされる。