朝イチ

django python

がっつり掘る。
とりあえず view ファンクション (って言うのだろうか) に渡されている request って何だ、とゆー事で。例えば Feedjack の views.py の initview 手続きの中で

    site_id, cachekey = fjlib.getcurrentsite(request.META['HTTP_HOST'], \
      request.META.get('REQUEST_URI', request.META.get('PATH_INFO', '/')), \
      request.META['QUERY_STRING'])

みたいなコトしてて可読性は良いのだけれど渡しているのは具体的に何か、というのはきちんと理解しておいた方が良さげ、とゆー事で

を確認中。

追記

request.META は_標準の Python 辞書オブジェクト_との説明があった。何だこれは、と言いつつ調べてみると hash な模様。アクセスの仕方的に

  • get メソド
  • ["hashkey"]

な方法がある模様。しかも get メソドは hit しなかった場合のデフォな戻りも指定可能らしい。なので

request.META['HTTP_HOST']

だと、HTTP_HOST な HTTP ヘッダが戻ってくるし（hit しない、というのはあり得ない前提）、

request.META.get('REQUEST_URI', request.META.get('PATH_INFO', '/'))

だと、REQUEST_URI を取りにいって失敗したら PATH_INFO を取りに行ってさらに失敗したら '/' を戻す、という風に読める。なかなかに便利ですな。

続き

python だとひらメソド使わなくても良い気がするのはなぜでしょうか。とりえずそれは良いとして Feedjack の views.initview について、ぱっと見で以下

  • cache の取得処理 (Site.id と cache key も取得）
  • モデルオブジェクトと id のリストの取得

最初のブロックで cache が取得できたら面倒な手続きは不要、という事で return している。そうでなければオブジェクトを取得して云々という処理。ここで cache 関連な作業をしないのは何らかの理由がありそげですが、現時点では不明。
もう少し詳細に掘り下げてみると以下

  • cache の取得処理
    • fjlib.getcurrentsite 手続きの呼び出し
    • 引数は以下を指定
      • HTTP ヘッダの HTTP_HOST
      • HTTP ヘッダの REQUEST_URI 又は PATH_INFO 又は '/'
      • HTTP ヘッダの QUERY_STRING
    • site_id と cachekey が戻る
    • 上記を引数に fjcache.cache_get 手続きの呼び出し
    • 戻った response が None でなければ以下を戻す
      • response
      • None
      • cachekey
      • []
      • []
  • モデルオブジェクトと id のリストの取得
    • モデルオブジェクトの関係として
      • Site は複数の Subscriber を持っている（可能性がある）
      • Feed は複数の Subscriber を持っている（可能性がある）
    • ということは
      • Site と Subscriber は 1 : n
      • Feed と Subscriber も 1 : n
      • Site と Feed は n : n
    • 戻すのは
      • None (cache 存在しないため)
      • 一つの Site オブジェクト
      • cachekey
      • Site オブジェクトに紐がついてて有効な Subscriber オブジェクト (??) のリスト
      • Subscriber オブジェクトに紐がついてる Feed オブジェクトの id のリスト

になるのかなぁ。fjlib.sitefeeds 手続きが戻している

return siteobj.subscriber_set.filter(is_active=True).select_related()

が何か、を微妙にイメージできてない？あるいは views.initview 手続きの

sfeeds_ids = [subscriber.feed.id for subscriber in sfeeds_obj]

とゆーソレも微妙。可読性は良いんですが、本当かどうか、という (を
たとえば上のナニは

siteobj に紐がついてる subscriber 達のうち is_active な（あら？）

やっぱ資料見たほうが良いな。で、データベース API リファレンスによると_自動で外部キーのリレーションを「追跡」_とある。次で Subscriber に紐がついた Feed オブジェクトな操作をしているのでついでに読んでる、という風に見えますな。いやはや。
あるいは次のナニは

siteobj に紐がついてる subscriber 達それぞれに紐ついた feed な id をリストにする

ってカンジでしょうか。類推ってのも微妙ですが、意味がなんとなく分かる、というのはすごい。