ラベル Python の投稿を表示しています。 すべての投稿を表示
ラベル Python の投稿を表示しています。 すべての投稿を表示

2011年3月16日水曜日

Python で Xcode のビルドスクリプトを書く方法

以前こんな記事を書きましたが、今回はもっと実践的なお話。PythonでXcodeのビルドスクリプトを書いてハッピーになろうというお話です。


■なぜXcodeのビルドスクリプトを書くのか

Xcodeのビルド機能だけでは出来ないことをやりたいからです。たとえば、
  • 特定のディレクトリの中に入っているリソースを、ビルド時にアプリにパッケージングしたい。
  • ビルドする前に、特定のリソースを暗号化して、アプリにパッケージングしたい。
といった要望が結構ありますが、これらはビルドスクリプトを使えば簡単に可能になります。
手でいちいちやるより楽で安全ですね。


■なぜPythonか

理由はいくつかあります。
  1. Windows, Mac, Linux, 全ての環境で動く。したがって、万が一のときにはビルドスクリプトだけを移植できる。
  2. sh とか csh とか非力すぎてやってらんない。 zsh もつかえるけど Python よりはやはり弱いと思う。
  3. スクリプトを Xcode 内部のエディタで書いて、そこに閉じ込められてしまうため、可搬性が無くなってしまう。
  4. 外部スクリプトにしておくと、引数としてオプションを渡せるので、ビルド設定に応じてオプションを切り替えたり、テストと本番でオプションを切り替えて動作を変更する、とかできる
たとえばクライアント・サーバーアプリで、サーバー側がPythonで出来ていたりする場合、
サーバー側の処理を一部ビルド時にやりたいとかあったりするわけですよ。・・・たまに。・・・ごくまれに。
そういうときに便利です。


■例:

長々と語るより例を示した方がよいと思うので、さっそくビルドスクリプトの例を示します。
ここでご紹介するのは、プロジェクトの/Resources/MyResourceディレクトリ以下にあるファイルを全てアプリバンドル内の/MyResourcesディレクトリ以下にコピーするだけの簡単なビルドスクリプトです。オプションとして平文/暗号化の有無を選択できるようにしてみました(実装はしてないです><)

Xcodeがビルドスクリプトを実行する際に、環境変数にたくさんの情報をセットしてくれます。なので、Pythonの os.environ を使ってそれらの情報を拾っていきます。Xcodeがセットしてくれる環境変数についてはhttp://developer.apple.com/library/ios/#documentation/DeveloperTools/Reference/XcodeBuildSettingRef/0-Introduction/introduction.htmlにまとめがあります。

#! /usr/bin/env python
# coding: utf-8

import os
import shutil
from optparse import OptionParser

def main():
# Option parser settings
#
description = """Sample build script"""
package_type_choices = (
'plain',
'crypted',
)
parser = OptionParser(description=description)
parser.add_option('-t', '--type',
action='store',
type='choice',
choices=package_type_choices,
default=package_type_choices[0],
dest='package_type',
help='Type of the destination package',
metavar='TYPE')
(options, args) = parser.parse_args()
print "*** Begin packaging resources. Package type is %s. ***" % options.package_type
# Env var settings
#
src_resources_path = "%s/Resources/MyResources" % (
os.environ['SRCROOT'],
)
destination_resources_path = "%s/%s/MyResources" % (
os.environ['TARGET_BUILD_DIR'],
os.environ['UNLOCALIZED_RESOURCES_FOLDER_PATH']
)
# Create target dir
#
print "*** Creating the destination MyResources directory at %s ***" % destination_resources_path
if os.path.isdir(destination_resources_path):
shutil.rmtree(destination_resources_path)
os.mkdir(destination_resources_path)
# Copy each resources in src_resources_path to the destination
#
for root, dirs, files in os.walk(src_resources_path):
for dir in dirs:
# TODO: This implementation is only for 'plain' packaging. Implement the 'crypted' packaging later
print "*** Copying the resource %s to the target build location ***" % dir
fromdir_path = os.path.join(root, dir)
todir_path = os.path.join(destination_resources_path, dir)
shutil.copytree(fromdir_path, todir_path)
print "*** Removing garbage files from the copied resource ***"
for r, ds, fs in os.walk(todir_path):
for f in fs:
# .から始まるファイルをゴミファイルと見なしてパッケージに加えないようにします
if f.startswith('.'):
os.remove(os.path.join(r,f))
print os.path.join(r,f)
# Make sure not to traverse into the subdirectories
del dirs[0:len(dirs)]
# Completed
#
print "*** Packaging resources is successfully completed! ***"

if __name__ == "__main__":
main()
はい、できました。Pythonを使ったメリットとして、 optparse モジュールのおかげでオプションを扱うのがすごく楽にできるとか、リストを扱うのが強力とかが見て取れます。ファイル名の文字列加工も shやcsh の中で sed を使うより安全でらくちんです。


■Xcodeから呼び出す

あとはこれをXcodeのビルド時に呼び出すようにしてやれば良いだけです。

Xcode 3の場合には、画面左のナビゲーションバーからターゲットを選択して、「新規ビルドフェーズを追加」→「スクリプトの実行」とかで出来たと思います。
Xcode 4の場合には、以下の画像が示すとおりにすればOKです。



はい、出来ました。あとはビルドするたびに毎回このスクリプトが実行されてくれるわけです。

画像では紹介してないですが、もちろん呼び出し時にオプションをつけたりできますよ。
/usr/bin/env python $SRCROOT/bin/mybuildscript.py --myoption=1 -v --enable_my_secret

2011年1月9日日曜日

Python で 5 分でちょっとした XML ファイルを生成する

なんだか西尾先生が面白そうなことをしてるので、便乗してみることにしました。


■課題

今お仕事で iOS のアプリを書いているのですが、その中で次のような plist ファイルを作成する必要が出てきました。 plist ってのをご存じない方は、要するに XML ファイルだと思ってください。
    <dict>
<key>emojiName</key>
<string>表情(嬉しい)</string>
<key>emojiCode</key>
<string>0xE415</string>
</dict>
<dict>
<key>emojiName</key>
<string>表情(にこにこ)</string>
<key>emojiCode</key>
<string>0xE056</string>
</dict>
<dict>
<key>emojiName</key>
<string>表情(笑顔)</string>
<key>emojiCode</key>
<string>0xE057</string>
</dict>
こんな感じで全部で400項目ぐらい。Webページの資料があるので、そこから転載して上記のような plist にするお仕事です。

私がやってもいいのですが、あいにく手が回りません。そこで最近弊社に入社してきました新人さんにお願いすることにしました。ところがどっこい、本当に一個ずつ手で書いているからなかなか作業が進みません。ほかのお仕事もあるのですが、二日でやっと5分の1程度。これはどげんかせんといかんですね。


■さっそくやってみよう

まずは下準備として、ExcelにWebページから情報を貼り付けて整理します。Excelを中間エディタとして使うことで、行と列の操作が簡単になりますし、そのままコピペするだけできれいに表が完成します。整理し終わったら、Excelからテキストエディタにコピペすると、以下のような TSV (Tab Separated Value) になります。
猫 0xE04F
いぬ 0xE052
ねずみ 0xE053
うさぎ 0xE52C
あとはこれを XML にするだけです。さっそくPythonでやってみましょう。
#!/usr/bin/env python

data = u"""
ここに先ほどのTSVをコピペしてください
"""
template = u"""
<dict>
<key>emojiName</key>
<string>%s</string>
<key>emojiCode</key>
<string>%s</string>
</dict>
"""

lines = data.strip().sprit('\n')
for line in lines:
t = line.sprit('\t')
print template % (t[0], t[1])

すごい原始的なコードですが、これでも十分動きますし簡単です。ってあれ、これ元ネタの西尾先生のコードとほとんど同じじゃないですか><


■その結果

まぁそんなこんなで無事 Python のコードもできたので動かしてみましょう。するとあっというまに目的のXMLが画面に出力されました!こうしてなんと残りの5分の4がたったの半日で終わってしまいました!単純な作業は工夫して楽に楽しく素早く片付けてしまいたいですね。

そうそう、ExcelやGoogle Docsのスプレッドシートを一時作業用に使うのはおすすめです。なんだかんだで表を作るならすごく操作しやすいですし、その後作った表をテキストエディタにコピペすれば TSV が簡単に作れるので、便利です。

2010年7月10日土曜日

virtualenv が上手く動作しない場合は -p オプションと --distribute オプションを試す

Python Hackathon という変態の巣窟に来ています。 virtualenv と buildout のハンズオンを受けているのですが、いくつか詰まった点があったのでメモ。

■virtualenv
普通にインストールするとき(ベースとなるpythonのsite-packageを受け継がないようにする場合)は以下のようにします。
python virtualenv.py --no-site-package myenv
ですがこの方法ではMac OS X 10.6付属のPython 2.6.1ではエラーになってしまいました。
New python executable in foo/bin/python
ERROR: The executable foo/bin/python is not functioning
ERROR: It thinks sys.prefix is '/System/Library/Frameworks/Python.framework/Versions/2.6' (should be '/private/tmp/virtualenv-1.4.3/foo')
ERROR: virtualenv is not compatible with this system or executable
そこで https://bitbucket.org/ianb/virtualenv/issue/17/virtualenv-not-working-with-default-python-on-mac-os を参考にして回避策を探してみたところ、
python virtualenv.py --no-site-package -p /usr/bin/python myenv
のようにして-pオプションを使いベースとなるPythonのパスを明示的に指定することで上手い具合にインストールできました。


■buildout
buildoutのbootstrap.pyをダウンロードしてきて実行すればよいのですが、Mac OS X 10.6付属のPython 2.6.1のsetuptoolsはバージョンが低い(0.6c9)ため、以下のようなエラーが出てしまうことがあります。
akisute server$ python bootstrap.py 
The required version of setuptools (>=0.6c11) is not available, and
can't be installed while this script is running. Please install
a more recent version first, using 'easy_install -U setuptools'.

(Currently using setuptools 0.6c9 (/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python))
もちろんsetuptoolsのバージョンを上げてもいいのですが、あまりデフォルトの環境を汚したくありません。そこで--distributeオプションを使用します。
python bootstrap.py --distribute
こうすると、distributeというsetuptools上位互換のモジュールが自動的にbuildout環境下にインストールされ、その結果上手い具合にインストールに成功します。buildout環境下へのインストールなのでデフォルトの環境は汚れません。すばらしい。

2010年2月28日日曜日

Sphinx の Blogger 原稿用拡張を作ってみました

Bloggerの原稿をいちいち手で書くのが面倒だったので(特にリストとかpreとか)、Sphinxを使ってBloggerの原稿を書く拡張を作ってみることにしました。
参考にしたページはこちら。
http://sphinx.shibu.jp/


■サンプルとダウンロード

githubにアップしてみましたので、こちらからご利用いただけます。
http://github.com/akisute/sphinx_rst2blogger

実際に変換させてみたサンプルをこちらに用意してみました。
http://gist.github.com/317478


■設定

完全に私の個人使用向けになっているので、そのままではたぶん使いにくいと思います。まずはMakefileの以下の部分をご自身の環境に合わせて書き換えてください。
blogger:
$(SPHINXBUILD) -b blogger $(ALLSPHINXOPTS) $(BUILDDIR)/blogger
mate $(BUILDDIR)/blogger/draft.txt
@echo
@echo "Build finished. The draft pages are in $(BUILDDIR)/blogger."
今私は mate コマンドを使って結果をTextMateに表示するようにしていますが、これはTextMateがないと使えないので適当に消すなり pbcopy に書き直すなりすると幸せになれます。

また、Blogger側の以下の設定を有効にしてください。



■実際に使ってみる

使用方法はとっても簡単です。以下のコマンドをシェルから実行してください。
make blogger
make.batは全く操作していないのでWindowsの人はごめんなさい。たぶん使えません><

また、100%完璧な変換はできておらず、主にpreとかtitleの箇所で手動微調整が必要になります。まぁおおよそ上手くやってくれればいいや、という考えです。


■おまけ:Sphinxの拡張機能でカスタムのビルダーを作る方法

拡張機能の作り方自体は以下のページのやり方に沿えば楽勝です。
http://sphinx.shibu.jp/extensions.html
ですが、肝心のビルダーを作るのはかなり苦労しました。

ビルダーの作り方ですが、一から手で書くと挫折するので、もともとSphinxに付いているビルダーをまるごとコピーしてそれを修正するようにすると比較的楽でした。リファレンスとかドキュメントとかないので、ソース見て、 visit_hogehoge とか depart_hogehoge とか書いてあるところを適当に修正してみたら動いた、って感じです。 TextBuilder を元にすると書きやすかったです。 HTMLBuilder はdocutilの機能を拡張しているためdocutilがわからないとさっぱり分かりません。

2009年12月16日水曜日

bulkloader.py を使って Google App Engine の本番サーバーから開発サーバーにデータを移す

Google App Engine SDKの開発サーバーのデータストアはtmpディレクトリにデータを保存するため、マシンを再起動するとデータの中身が全部消えてしまいます。毎回テストデータを用意するのが面倒なので、本番サーバーからデータを移してくるための方法を調べてみました。するとbulkloader.pyというユーティリティを使うと、簡単に本番サーバーのデータをダウンロードして保存し後からリストアすることができることがわかりました。ということで早速試してみます。
参考にしたのは以下のサイト。
http://code.google.com/intl/en/appengine/docs/python/tools/uploadingdata.html

※2010/01/31追記:--db_filenameオプションの使い方を掲載しました。


■前準備
app.yamlに以下の設定を追加してから、appcfg.py updateで本番デプロイを行います。
- url: /remote_api
script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
login: admin
これだけで準備ばっちりです。余談ですが、app-engine-patchを使うと、最初からこの設定がapp.yamlに含まれています。


■使用方法
本番サーバーからローカルにデータをダンプするときは以下のコマンドを実行します。
bulkloader.py --dump --kind=<kind> --url=http://<appname>.appspot.com/remote_api --filename=<data-filename>
たとえば私のアプリからhon_heroという名前のModelのデータをダンプしたいときには、
bulkloader.py --dump --kind=hon_hero --url=http://akisutesama.appspot.com/remote_api --filename=hon_hero.dump
などとするとうまくいきます。

ダンプしたデータを本番サーバーにリストアするときは以下のコマンドを実行します。
bulkloader.py --restore --kind=<kind> --url=http://<appname>.appspot.com/remote_api --filename=<data-filename>
--dumpが--restoreになっただけです。本番障害でデータが失われたときにリストアするためのコマンドなので、実行すると本番サーバーのデータがすべてダンプした地点のデータに置き換えられます。ご利用の際には細心の注意を!

ダンプしたデータをローカルサーバーに入れるときは以下のコマンドを実行します。
bulkloader.py --restore --kind=<kind> --url=http://localhost:8080/remote_api --filename=<data-filename> --app_id=<appname>
本番だけではなくてローカルサーバーにもリストアができます。ローカルサーバーにリストアする際の注意点として、
  • dev_appserver.pyでアプリケーションが動いている必要があります。
  • --urlオプションをローカルホストに書き直す必要があります。
  • --app_idオプションで、自分のアプリケーションのapp_idを指定してやる必要があります。
これでローカルテストがだいぶ楽になりました。

同様にして、本番からデータをダンプしてローカルに入れるだけでなく、ローカルからデータをダンプして本番に入れることもできます。新しく実装した箇所に最初からデータを入れたい場合などに使えると思います。


■log, progress, resultを賢く使う
bulkloader.pyを実行すると、デフォルトでは以下のような名前のファイルが自動的に生成されると思います。
bulkloader-log-20091211_145622.log
bulkloader-progress-20091211_145622.sql3
bulkloader-result-20091211_145622.sql3
これらはそれぞれ「ログファイル」「現在どのエンティティまでダンプされたかを格納するデータベース」「実際にダンプした内容を格納するデータベース」となっており、上手く使えば2回目以降のダンプ実行時間を劇的に短くすることができます。

ログファイルを指定する際には--log_fileオプションを、データベースを指定する際には--db_filenameと--result_db_filenameを、それぞれ指定してください。たとえば、以下のようなシェルスクリプトを用意しておくと便利です。
#!/bin/sh

# 前回の実行結果が残っているとエラーになる(上書きしてくれない)ので、まずいったん消す
if [ -e hon_hero.dump ]; then
rm hon_hero.dump
fi
# bulkloader.pyを実行する
# db_filenameとresult_db_filenameは一緒のファイルを指定してもかまいません。
# (その場合は、一つのsqlite3データベースに一緒に格納されます)
# db_filenameとresult_db_filenameは、db_fileやresult_db_fileのように短縮して書いても動作するみたいです
bulkloader.py --dump \
--url=http://akisutesama.appspot.com/remote_api \
--kind=hon_hero \
--filename=hon_hero.dump \
--log_file=bulkloader-log-hon_hero.log \
--db_file=bulkloader-progress-hon_hero.sql3 \
--result_db_file=bulkloader-progress-hon_hero.sql3
こうすることで、2回目以降はbulkloader-progress-hon_hero.sql3の中身とリモートのdatastoreの中身を比較して、追加更新のあったもののみをダウンロードし、それ以外はローカルに保存してあるデータベースの中身を利用するので、劇的に処理が速くなります。結果はこちら。
[INFO    ] Connecting to akisutesama.appspot.com/remote_api

[INFO ] Have 2610 entities, 2610 previously transferred
[INFO ] 2610 entities (974 bytes) transferred in 0.4 seconds
1回目のロードには130秒かかったのですが、2回目はすべてローカルに保存されているデータを使ったので、なんと0.4秒で済んでいます。

こうしてダンプしたデータをローカルサーバーでリストアするときは、たとえば以下のようなシェルスクリプトを使います。
#!/bin/sh

# --db_fileと--result_db_fileには先ほどのダンプ時に指定したものとは別のファイルが必要になります
# (先ほどのデータベースはappspot.com用として設定されるので、localhostで使用するとエラーになってしまいます)
# --db_fileと--result_db_fileには特別な名前としてskipを指定することができます
# この名前を使用するとデータベースへの書き込み/読み込みを行いません
bulkloader.py --restore \
--url=http://localhost:8000/remote_api \
--app_id=akisutesama \
--kind=hon_hero \
--filename=hon_hero.dump \
--log_file=bulkloader-log-restore.log \
--db_file=skip \
--result_db_file=skip


■注意点
appspot.com以外のサーバー(たとえばlocalhostなど)からデータをdumpしたりrestoreしたりする際には、必ず--app_idオプションを指定する必要があります。これを忘れていて詰まりました><

もし特定の条件を満たすデータのみをダウンロードしたいという場合などは、設定ファイルをPythonで書く必要がありますが、appcfg.py download_dataを使うと良いと思います。

2009年12月11日金曜日

Django の Template Filter には任意の変数を使用することができる

公式ドキュメントに記載がなかったので、自分用メモ。

たとえばDjangoのフィルターで、
{{ some_value|floatformat:1 }}
としているところを、viewから変数を渡して
{{ some_value|floatformat:floatpoint }}
のように書くことができます。他にも
{{ now "%Y %m %d" }}
{{ now date_format }}
みたいに書くとか。・・・常識?

2009年12月1日火曜日

Google App Engine SDK の dev_appserver.py が自動的に index.yaml を更新してくれない時の対処法

ときどきGoogle App Engine SDKのdev_appserver.pyが自動的にindex.yamlを更新してくれない時があるので、原因を調べてみました。


■いきなりネタバレ
犯人は改行文字


■前提条件
index.yamlは、以下の様な作りになっています。
indexes:

- kind: django_admin_log #手動で定義したインデックス
properties:
- name: content_type
- name: object_id
- name: action_time

# AUTOGENERATED

# This index.yaml is automatically updated whenever the dev_appserver
# detects that a new type of query is run. If you want to manage the
# index.yaml file manually, remove the above marker line (the line
# saying "# AUTOGENERATED"). If you want to manage some indexes
# manually, move them above the marker line. The index.yaml file is
# automatically uploaded to the admin console when you next deploy
# your application using appcfg.py.

- kind: hon_herostatistics #ここから下は、自動的にdev_appserver.pyが追加してくれるindex
properties:
- name: fetchCompleted
- name: hid
- name: datetimeCreate
direction: desc
このように、# AUTOGENERATEDコメントが存在すれば、その下に自動的に必要なindexを生成してくれるようになっているのですが、時々この自動生成がうまくいかない場合があります。


■症状
具体的には、以下のように余計な物をすべて消した状態のindex.yamlを用意しても、dev_appserver.pyが「indexが手動定義されているので、自動生成しないよ」とエラーを吐きます。
indexes:

# AUTOGENERATED
困りました。


■原因と対処
そこでよくよく調べてみるためにvimではないエディタでこのindex.yamlを開いてみたのですが、すると末尾の改行文字がCRLF(dos形式)になっていました。そこで私のMacの環境に合わせて改行文字をLF(unix形式)にしてみたところ、無事にdev_appserver.pyのindex自動生成が動作するようになりました。vimで操作するなら、
:set fileformat=unix
とすればよいです。

2009年10月17日土曜日

PythonのEvernote APIをProxyに対応させることに成功しました

前回記事で見事大失敗したので、今回改めてThriftのTHttpClientのPython実装にProxy機能を持たせるチャレンジを行いました。結果、無事成功しました!さっそく共有させていただきたいと思います。


■PythonのEvernote APIをProxyに対応させる方法
まずはEvernote APIの中で使用されている通信クラス、thrift.transport.THttpClientを修正する必要があります。
以下のようにTHttpClient.pyを修正してください(または別名ファイルとして保存してください)。

http://gist.github.com/204501

修正しましたら、APIを呼びだす側のコードを以下のように変更してください。
# これを・・・
# import thrift.transport.THttpClient as THttpClient
# こうする
import thrift.transport.MyTHttpClient as THttpClient
import evernote.edam.userstore.UserStore as UserStore
import evernote.edam.userstore.constants as UserStoreConstants
import evernote.edam.notestore.NoteStore as NoteStore
import evernote.edam.type.ttypes as Types

##########
# 中略
##########

# プロキシを使わなくて良いときはproxy引数を無視すればよい
# userStoreHttpClient = THttpClient.THttpClient(userStoreUri)
# プロキシを使いたいときはこうする
userStoreHttpClient = THttpClient.THttpClient(userStoreUri, proxy="myproxy.example.com:8080")
userStoreProtocol = TBinaryProtocol.TBinaryProtocol(userStoreHttpClient)
userStore = UserStore.Client(userStoreProtocol)

versionOK = userStore.checkVersion(applicationClientNameString,
                                   UserStoreConstants.EDAM_VERSION_MAJOR,
                                   UserStoreConstants.EDAM_VERSION_MINOR)
これだけで通信時にプロキシを介してくれるようになりました!


■何をやっているか
そもそもThriftのTHttpClientはプロキシを使うこと自体が全く想定されていない?作りになってまして、他の言語の実装でもすべてプロキシは使えるようになっていません。たとえばC#での実装はこちら(http://issues.apache.org/jira/secure/attachment/12391517/THttpClient.cs)ですが、これもプロキシは使えません。connection.Proxy = null;ってなってます。

というわけで、勝手に自分でTHttpClientを再実装してプロキシを使えるようにしています。あんまりよい方法ではないと思いますので、本番サーバーなどでは真似しないでください><


■前回からの改良点
前回はhttplib.HTTPを使うのを辞めて、httplib.HTTPConnectionクラスを使うようにしたのですが、コレがそもそもの大失敗でした。といいますか、httplib.HTTPのソースを見たら内部でばっちりhttplib.HTTPConnectionが使われてるじゃないですかorz
self.__http = httplib.HTTP(self.host, self.port)
self.__http._conn #これでhttplib.HTTPConnectionが取得できる
そして前回最大の失敗がread()メソッドが呼ばれるたびに接続をcloseしてしまっていたところです。httplib.HTTPの実装をみてようやく気づいたのですが、ここでは接続をCloseしてはいけないんですね・・・
これらを踏まえて、今回はTHttpClientの中でhttplib.HTTPをそのまま使うようにして解決しました。

他にもhttplib.HTTPResponseは以下のようにしてファイルポインタが取得できるとか
response = conn.getresponse()
response.fp # これがファイルポインタ。httplib.HTTP.read()でも使われている
httplibはとにかくドキュメントに書いてない仕様が多すぎです><

2009年10月8日木曜日

PythonのEvernote APIをプロキシに対応させようとして挫折した

Evernote APIで使用されているThriftのTHttpClientクラスには、プロキシの設定を行うためのインターフェースが用意されていません。そのため、プロキシ越しにEvernote APIの呼び出しを行うことが出来ないみたいです。
(ひょっとしたら出来るのかもしれませんが、調べた範囲ではわからず)

そこでThriftのTHttpClientクラスのPython実装をプロキシに対応させるべくチャレンジしてみました。

http://gist.github.com/204501

基本的には元々httplib.HTTPで実装されていたところをhttplib.HTTPConnectionに変えただけなのですが、ところがこれがうまくいかない。このクライアントで/edam/user/にCheckVersionリクエストを投げると500エラーが返却されてしまいます。で、500エラーを拾うと再度試行するようになっているのか、あえなく無限ループに突入><
プロキシの設定が間違っているのかと思い、試しにプロキシを外してデバッグログをはかせた結果がこちら。
send: 'POST /edam/user HTTP/1.1\r\nHost: sandbox.evernote.com:443\r\nAccept-Encoding: identity\r\nHost: sandbox.evernote.com\r\nContent-Type: application/x-thrift\r\nContent-Length: 82\r\n\r\n'
send: '\x80\x01\x00\x01\x00\x00\x00\x0ccheckVersion\x00\x00\x00\x00\x0b\x00\x01\x00\x00\x00(Python URL to Evernote/0.1; Python/2.5.2\x06\x00\x02\x00\x01\x06\x00\x03\x00\r\x00'
debug: HTTPConnection
Request-sent None
reply: 'HTTP/1.1 200 OK\r\n'
header: Server: Apache-Coyote/1.1
header: Content-Type: application/x-thrift
header: Content-Length: 29
header: Date: Wed, 07 Oct 2009 09:04:29 GMT
read start
read POST request
send: 'POST /edam/user HTTP/1.1\r\nHost: sandbox.evernote.com:443\r\nAccept-Encoding: identity\r\n\r\n'
read getresponse
debug: HTTPConnection
Request-sent None
reply: 'HTTP/1.1 500 \r\n'
header: Server: Apache-Coyote/1.1
header: ETag: W/"3401-1254794526000"
header: Last-Modified: Tue, 06 Oct 2009 02:02:06 GMT
header: Content-Type: text/html
header: Content-Length: 3401
header: Date: Wed, 07 Oct 2009 09:04:29 GMT
header: Connection: close
read start
read POST request
うーん、HTTPSの実装が間違っているのか、リクエストパラメータが間違っているのか。1回目のリクエストはうまくいくけど2回目のリクエストが失敗しがちみたいです。もう少し調査してみます。


あ!今気づいた!!
2回目のリクエスト時(readメソッド実行時)のHTTPヘッダがめちゃくちゃだ!!ここを直せば動くかも。

2009年10月5日月曜日

Evernote APIためしてみた


API Keyくださいとお願いしたらすぐに発行してもらえたので、試しにEvernote APIを触ってみました。


■準備
http://blog.lilyx.net/2008/11/03/evernote-api/を見ると発行するときに手間がかかったとの記述がありましたが、私の場合は半日で発行されました。まぁ1年たってますし、状況が良くなったのかもしれませんね。申請時にアプリの詳細を事細かに書いたのが良かったのかもしれません。


■Hello Worldを動かす
まず最初にsandbox環境に自分用のアカウントを作成します。http://sandbox.evernote.com/login.jspにアクセスして、いつも通りアカウントを作成。忘れがちなので注意です。
アカウントが出来たら、ダウンロードしてきたSDKに最初っからサンプルスクリプトがついてきているので、こちらを実行するだけです。今回はPythonのサンプルスクリプトを試してみました。
cd sample/python
cp * ../../lib/python
cd ../../lib/python
python EDAMTest.py username password


■ENMLを試してみる
今回の最終目的は「はてブみたいにURLだけ渡したら勝手にEvernoteに取り込んでくれる」ことなので、まずはどのぐらい気軽にHTMLを取り込めるかを調べてみました。Evernoteの本文はENMLというHTMLに似たマークアップ言語で記述されています。
http://www.evernote.com/about/developer/api/evernote-api.htm#_Toc200272588
こちらの記載を読んでみたところ、かなーーーーーり面倒くさいということが判明。htmlタグやbodyタグが含められないのはまだいいとして、id属性もclass属性も許可されません。さらに困ったことに・・・

pタグ閉じてないからダメー。


brタグ閉じてないからダメー。

さすがXML、厳しい。どうやらHTMLとは全く互換性がないと考えた方が良さそうです。
HTMLをENMLに変換するライブラリとかないかなー?

ENMLは死ぬほど面倒ですが、それ以外のところは今のところ簡単です。

2009年9月8日火曜日

Mac OS X 10.6 Snow Leopardのeasy_installでPILをビルドするときに気をつけることなど

Snow LeopardにPIL(Python Imaging Library)をインストールしようとして見事にハマりましたので、後学のために事の顛末を記しておきます。


■まず最初に、調べて分かった結論
  • Snow LeopardでPythonを使うときは、デフォルトで付属しているPython 2.6.1を使用すること。
  • Snow LeopardにはPython 2.5.4も付属しているが、こちらは使用するべきではない。
  • Snow LeopardのPython 2.5.4のdistutilには不具合?があり、UnixCCompilerクラスがC言語のモジュールを64bitでビルドしてくれないため、Snow Leopardでは動作しなくなる
  • したがって、C言語のモジュールを使用しているPILはSnow LeopardのPython 2.5.4を使うとビルド出来ない
  • どうしても2.5.4を使いたいときには、環境変数にARCHFLAGS "-arch x86_64"を追加してからPILをビルドするとうまくいくかもしれない(未確認)
  • MacPortやMacPythonからのインストールは実験していないため未確認

※ あくまで2009年9月8日現在での断片的な情報です。皆様がごらんになっている時点では既にMacPort上のPythonやMacPythonも対応を完了しているかもしれませんので、参考程度にご覧ください。でもSnow Leopard上のPython 2.5.4はほんとお勧めしません。


■ことのはじまり
Leopardのころはきちんと動いていたGoogle App Engine SDKが、Snow Leopardにアップグレードしたとたん突然PILモジュールがないと警告を出すようになってしまいました。確認してみると/Library/Python/Python2.5/site-packages/以下に確かにインストールされているのですが、何度試しても警告が消えません。Pythonのバージョンも以前から使っているPython 2.5のままです。これは何かがおかしい、再インストールした方がいいだろうと判断し、http://www.pythonware.com/products/pil/から1.1.6のソースコードを落としてきていざビルド。
sudo python setup.py install
python selftest.py
・・・が、動きません。なにやらImagingMathが見つからないだのなんだのとエラーが出てしまいます。これだけではよく分からないので、直接PILのモジュールをPythonからimportしてみることにしました。
akisute PIL$ python2.5
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Imaging
>>> # 問題なくインポートできました
>>> import _imaging
Traceback (most recent call last):
File "", line 1, in
ImportError: dlopen(./_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Python/2.5/site-packages/PIL/_imaging.so
Expected in: flat namespace
in /Library/Python/2.5/site-packages/PIL/_imaging.so
>>>
ふむふむ、どうやらこの_imaging.soというのがなにやら悪さをしているようです。@tokibito先生にお尋ねしたところ、このsoファイルというのはC言語のソースをコンパイルしたライブラリで、Pythonから動的にインポートできるようにpython.hというヘッダをインクルードしてつくられているらしいということが分かりました。なるほど、それでPythonから直接C言語で書かれてビルドされたライブラリをimportできるんですね。凄いなPython。

となると怪しいのはPILのビルド工程。先ほどのエラーを見ると_jpeg_resync_to_restartというシンボルが見つからないと表示されていたため、インストールに使ったlibjpeg(MacPortよりインストール)に何か問題があったのではないかと推測したのですが、特に問題は見つからず。

次にPILのビルドログを調査。細かいwarningが出まくるのはいつものことなので無視して調べてみますが、一見何もエラーは出ていません。するとあることに気づきました。
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc build/temp.macosx-10.6-i386-2.5/_imaging.o build/
temp.macosx-10.6-i386-2.5/decode.o build/temp.macosx-10.6-i386-2.5/encode.o build/temp.macosx-10.6-i386-2.5/map.o build/
----
中略
----
-L/o
pt/local/lib -L/System/Library/Frameworks/Python.framework/Versions/2.5/lib -L/usr/lib -ljpeg -lz -o build/lib.macosx-10
.6-i386-2.5/_imaging.so
うん、なるほど、原因が分かりました。-arch i386と -arch ppcでしかビルドされていないのがまずそうですね。Snow Leopardは64bitですから、-arch x86_64を追加してビルドしなければならないはずです。

ためしにPython 2.6.1でこの_imaging.soを読み込もうとしてみた結果がこちら。
akisute PIL$ python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _imaging
Traceback (most recent call last):
File "", line 1, in
ImportError: ./_imaging.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
>>>
ビンゴ!間違いなさそうです!あとは、どうすれば64bitでビルド出来るかを調べるだけです。


■distutilとの戦い
とは言ってみたものの、そもそも一体全体どういうカラクリでpython setup.py installコマンドがgccビルドを実行しているのかが分かりません。まずはsetup.pyのソースを読んでみることにしました。するとdistutils.command.build_extなるモジュールをimportして使っていることが判明。怪しい。Python2.5のシステムライブラリをあさってみると、ありましたありました。


さっそくコードを読んでみると・・・
475         objects = self.compiler.compile(sources,
476 output_dir=self.build_temp,
477 macros=macros,
478 include_dirs=ext.include_dirs,
479 debug=self.debug,
480 extra_postargs=extra_args,
481 depends=ext.depends)
おおっといきなり発見、self.compiler.compileとか怪しさ抜群です。こいつはどこからやってきたのかとソースをたどると、なにやらunixccompiler.pyというモジュールを発見。いかにも私がコンパイラだと言わんばかり。犯人はこいつに違いない。さっそくコードを開いて-archとかで検索をかけてみましたが、i386とかppcとか直接指定している箇所は見あたりませんでした。その代わり別の収穫を発見。
def _darwin_compiler_fixup(compiler_so, cc_args):
"""
This function will strip '-isysroot PATH' and '-arch ARCH' from the
compile flags if the user has specified one them in extra_compile_flags.

This is needed because '-arch ARCH' adds another architecture to the
build, without a way to remove an architecture. Furthermore GCC will
barf if multiple '-isysroot' arguments are present.
"""
----
中略
----
if stripArch or 'ARCHFLAGS' in os.environ:
while 1:
try:
index = compiler_so.index('-arch')
# Strip this argument and the next one:
del compiler_so[index:index+2]
except ValueError:
break

if 'ARCHFLAGS' in os.environ and not stripArch:
# User specified different -arch flags in the environ,
# see also distutils.sysconfig
compiler_so = compiler_so + os.environ['ARCHFLAGS'].split()
----
後略
----
環境変数ARCHFLAGSとかいうのを見てるみたいです。なるほど、じゃこいつに"-arch x86_64"とか追加すればきちんと64bitビルドしてくれるのでしょうか?


■そしてあっけない幕切れ
ここまでなんとか一人で調査していたものの、たまりかねた隣の席の皆さんからアドバイス。

「Python 2.6じゃないのがまずいんじゃね?」

え、何、そういうこと?まぁ念のために試してみるか、ということでPythonを2.6に切り替えて再度PILをビルド。

あ、-arch x86_64がビルドオプションについてる。

あ、python selftest.py一発で通った。

あ、Google App Engine SDKがPILの警告吐かなくなった。

終了。

なにそれ。俺の苦労、何よ。


■あれ?
・・・おかしいな、今日作るはずだったGoogle App Engineのアプリ、まだ10行ぐらいしか書いてないよ><

2009年9月3日木曜日

Python 2.5系列では__repr__()でunicodeを返すといろいろトラブルが起きる

Django(正確にはapp engine patch)のmanage.py shellで遊んでいるとき、とあるクラスを生成すると必ずUnicodeEncodeErrorが発生していることに気づきました。具体的には以下のような感じ。
>>> from game.models import *
>>> hts = HeroTemplate.all()
>>> ht = hts.fetch(1)[0]
>>> ht.template_name #問題なし
>>> ht.name          #問題なし
>>> hero = Hero(
... name=ht.name,
... symbol=ht.symbol,
... max_life=ht.max_life,
... life=ht.max_life,
... max_move=ht.max_move,
... move=ht.max_move,
... weapon=None,
... item=None,
... )
>>> hero             #ここでUnicodeEncodeError
>>> ht.createHero()  #上記と同じ処理をやるメソッド、これもUnicodeEncodeError
原因を調べていてわかったのですが、Python 2.5系列では__repr__()がunicodeを返すようにしてしまうとトラブルの元になってしまうようです。
参考にしたサイト:
http://d.hatena.ne.jp/alisue/20090402/1238690818

たとえば、
>>> class Abesi:
...   def __repr__(self):
...     return u'¥u3059¥u305a¥u304d¥u3044¥u3061¥u308d¥u30fc'
... 
>>> abesi = Abesi()
>>> abesi #UnicodeEncodeError
これを実行するとabesiを表示しようとしたタイミングでエラーになります。環境はWindowsXP上のCygwin 1.7 + Python 2.5.4で、ターミナル上ではshift_jisを使っています。始めっからターミナルがutf-8を扱えるような環境なら__repr__()でunicodeを返しても上手くいくかもしれません。
しかしながらどこの環境でも動くとはいいがたい状態なので、
  • __str__()と__repr__()はstrを返す
  • __unicode__()はunicodeを返す
Python 2.5系列ではこのルールを守っておいたほうが無難のようです。Python 3.0からはunicodeがデフォルトになるらしいのでこんな面倒ごとをいちいち考えなくてもよいのでしょうか?いまだにPython 3.0試していませんが、ちょっと興味が湧いてきました。


■っていうかそもそも
Djangoのdjango.db.models.Modelクラスは特にオーバーライドしなくても綺麗な__repr__()を出力してくれるので、デフォルトの__repr__()を使えばよかった><

2009年8月23日日曜日

Python Hackathon #1に参加してきました

http://atnd.org/events/649

Python Hackathon #1に参加してきました。主催はいつものごとくvの人。しかしながら幸いにして雨は降りませんでした。


■以下、適当にダイジェスト
会場がいつもの四ッ谷健保会館ではなく、大久保の健保会館だったため場所を間違える人が続出。
今回のハンズオンは、
  • id:tokibitoのパーフェクトdjango教室
  • Google App Engineハンズオン Kayを使ってみよう
  • Pythonソースコード読書会
の3本立てだったのですが、Pythonソースコード読書会が参加者0人のためあえなく中止><

私はというと社内ブログの投稿順序を記録して利マインドメール投げたりするためのアプリをひたすら書いてました。が、前日夜遅くまで東方をプレイしていたせいで半分意識がもうろう・・・
気がついたらもう18時になって終わっていた感じです。PyPyとかwxPythonとかPyQtとかjQueryのカスタムイベントの話とかをしていたそうなのですが、意識が無くほとんど聞けずちょっと後悔。しかし後悔先に立たず・・・

18時半から毎度おなじみ@moriyoshiのすべらない話。

(音小さくてすみません、iPhone 3GSの限界)
相変わらず面白いなぁ。しかし本人曰く「納得いかない、やり直したい」とのこと。凄いw


■懇親会
普段は懇親会お断りしているのですが、今回は禁酒の上で懇親会に参加してみました。
http://www.yamachan.co.jp/index.html
場所は大久保のこの店。この手羽がまた美味しい!普段は飲み会など参加しても3分の1人前も食べない私ですが、今回は思わず一人前完食。話も盛り上がってなかなか充実したひとときでした。


■はんせい
  • 前日はちゃんと寝ておこう
  • ソースコード書いてばっかりないでもっと話そう
逆に良かった点としては、ちゃんと必要なライブラリとか実行環境とかを用意してきたためスムーズに作業に入れたところと、懇親会に参加したところかな。
当日のTwitterで見られたつぶやきのうちに、「話しかけるきっかけがないまま終わってしまった」というものがありましたが、納得。この手の勉強会は勉強会の最中よりも懇親会の方が話が弾んで名刺の交換もはかどるので、懇親会には出た方がお得ですね。勉強会の最中は相手もコード書いてたりでなかなか話しかけづらい雰囲気なんですよねー。その点、id:mopemopeさんとかは気さくに参加者に話しかけてくださってて凄いと思います。一見しゃべってるばかりで何もしてなさそうなのですが、話しかけてこの勉強会の緩い雰囲気を保ってくださっているんだなぁと感心。自分ももっともっと話していきたいです><

2009年6月26日金曜日

第5回 Python温泉に参加中



第5回Python温泉に参加中です。以下、随時更新していきます。



■2009/06/26
16:00ぐらい
到着。挨拶もそこそこに早速Mac引っ張り出して開発開発。


18:46
晩ご飯準備中、いすがないので大の大人が20人も階段に座り込んだりたったままプログラム書いたり>< カオス><

19:00
ご飯。Pyspaグッズ販売について説明。Pyspaマグほしい。


19:56
晩ご飯終了。@moriyoshiがパンツ一丁で走り回っていたりとか。

21:04
最近書いてなかったうちにたまったネタでBlog更新。
@nakamura001さんにiPhone 3GSの良さを語ったりとか。

22:02
ひたすらプログラム。眠い、集中力が落ちてきているが何とかがんばる。
iPhone 3GSの新機能 VoiceOverを使ってsayコマンド祭りを試みるが、vの人に「感動を覚えない」と一蹴される><

22:25
眠い・・・寝るー。

■2009/06/27
6:56
おきったー。およそ7時間半睡眠。よほど疲れていたらしい。あと食い過ぎで胃がもたれている感じなので今日は自重する。軽く散歩して目を覚ましてから昨日の続きのコードを書く。
周りは死屍累々。徹夜と思われる4人以外全員寝てる。


7:00
layoutSubviewsの中で[super layoutSubviews];を呼び出してなくてセルがうまく描画されていなかった問題を修正。

8:26
朝ご飯終了。Python温泉鉄の掟のため、朝ご飯タイム(8時〜8時半)は強制的にたたき起こされます。

9:27
くぼけーさんと政治談義とか?やはり渡米して政治学とか専攻されている方は凄い、外から客観的に日本が見られるというのはいいな

10:00
コーディングコーディング。YourTurnのリファクタリングを行ったり。

11:00
お菓子買い出し


12:17
お昼ご飯&コーディング。隣で@nishioさんとvの人がErlangやらHaskelやらについて熱く議論してますが、1mmも理解できないので無視。何か論文みたいなのを確認しているようだが・・・いや、この人たちレベル高杉><

12:21
現在のタイムライン:
コンパイラーとかインタープリターとかCPUとか自作する?

CPU自作の本の表紙が萌え〜で買いづらい

もっと萌え〜なのと一緒に持って行けばいい

むしろオライリー本を萌え〜で挟んで持って行く

「何それ蛇とか萌え〜なのかしらこわい」

12:27
Python談義。@aodagさんがWerkZeuk嫌いですとかそういう話。
@moriyoshiの実装力&PHP力 + @nishiohirokazuの理論 + @tmatsuoのドキュメントスキル + 料理スキルという化け物プログラマの話(しかもニートらしい)

12:34
でもcommit logがひどい「impl」「impl」「impl」「impl「implばっかじゃねーか!」

12:43
rabbitMQのお話、@everesさんとvの人が戦争中
rabbitMQはzero-configulationだよ(ユーザーの追加だけ)!rpmでもyamでもapt-getでも入るよ!

14:56
お昼寝して散歩してリフレッシュ。



15:34
化学実験(コーヒーにドライアイスを投下などする)。

16:27
順調に進まない。あとは設定をつけるだけとか高をくくっていたのだが
設定をつけるって超大変じゃないか・・・

17:45
晩飯撤収タイム。いまのうちに温泉に行ってくることにする。

18:36
カードゲームタイム!


20:12
ご飯終了。カードゲームの続き。
隣では企業偏差値ランキングとかで盛り上がっているが。

22:18
@moriyoshi先生によるLiveプログラミング会(1時間半!)これは熱い!
なぜかjava.applet.Appletでボールを跳ね返すプログラムを作って遊んでいた。

続いて@ianmluiceの作ったSnippleというWebアプリの解説。タスクキューを使ったバックグラウンド処理とか、「メールボックスのような設計」とか(ある人が処理を行ったら、フォロワー全員のメールボックスにキューで処理を投げて、ある人がそのストリームを読めるようにする)

22:46
会議室に降りてきてラストスパート!

23:28
幕間設定できた!!


Just a small step for the world, but a giant leap for me!!

■2009/06/28
1:32
音ファイル設定も下地が完成。後は家に帰って音声素材を探してきて追加するだけ。
どうやら明日には予定通りApp Storeに提出できそうです。

2:00
就寝。

7:00
起床。

8:00
朝ご飯。

9:14
宿泊代金も支払って暇タイム。

10:04
10時より第6回Python温泉受付開始しました。開始5分で28人枠埋まりました。

11:00
解散!おつかれさまでした!

2009年4月26日日曜日

MacPortsを使って、Pythonの開発環境を整えてみた

ここ最近勉強会続きだったため、複数のバージョンのPythonの開発環境の整備をする必要に迫られました。
まずはPython2.6.2をインストールしようと考えたのですが、python.orgからdmgでダウンロードしてインストールすると余計な物をたくさんインストールされてしまいますし、何より環境の切り替えが大変です。
(Mac付属の2.5.1でないとDjangoがエラーを吐いたりするため、いつでも2.5.1に切り戻せるようにしたい)

そこで今回はMacPortsを使って開発環境を整えてみました。

■Pythonのインストール
これはMacPortsから以下のコマンドを実行するだけでいけました。
sudo port install python26

ただ、依存するモジュールが非常に多いためビルドに大変時間がかかりました。MacBook Airで、およそ1時間ぐらい。
これで/opt/local/Library/Frameworks以下にPython.frameworkがインストールされるのですが、インストールしただけでは自由に元々存在するPython 2.5.1との切り替えができません。
そこで、同じくMacPortsで提供されている、python_selectというスクリプトをインストールします。
sudo port install python_select

インストールしたら、以下のようにして自由にPythonのバージョンを切り替えることが出来ます。
$ python_select -l #利用可能なバージョン一覧を表示
Available versions:
current none python25-apple python26
$ python_select python26 #python2.6に切り替え

こいつは大変便利です。

■Djangoのインストール
DjangoもMacPortからインストールできます。
sudo port install py26-django

Djangoだけではなく、jinjaやSQLAlchemy, Werkzeugなど、名前の知られているPythonのフレームワークはすべて存在しているようです。とっても楽ちん。
ちなみにインストールできるportとしてpy25-djangoのようにPythonのバージョンを指定しているものと、py-djangoのように指定していないものがありますが、py-djangoをインストールしようとすると突然Python2.4をインストールしようとしやがりましたので、基本的にはPythonのバージョンを指定しているportを選んだ方が良さそうです。

さて、MacPortでインストールしたPythonのためにDjangoをインストールするのは簡単でしたが、
問題になってくるのは元々標準で入っているPython2.5.1のためにDjangoをインストールするときです。
easy_installが使えるようなので、今回はeasy_installを使ってインストールしました。
sudo easy_install django

ただしportと比較すると後からアンインストールするのが面倒だという欠点があります。portが使えるならportがいいですね。

■PILのインストール
PILのインストールも基本はMacPortで。
sudo port install py26-pil

問題はPython 2.5.1にインストールするときです。私の環境では、easy_installが失敗してしまい簡単にインストールできませんでした。
悩んだあげく、PILのウェブページからPython Imaging Library 1.1.6 Source Kitをダウンロードし、直接setup.pyを実行して解決しました。
tar zxvf Imaging-1.1.6.tar.gz
cd Imaging-1.1.6
sudo python setup.py install

2009年3月17日火曜日

Pythonで、特定のディレクトリ以下にあるすべてのモジュールをインポートする方法

Pythonで特定のディレクトリの下にあるすべてのモジュールをインポートしたいときの方法。
これもGAEOのソースから見つけました。
def initPlugins():
"""
Initialize the installed plugins
"""
plugins_root = os.path.join(os.path.dirname(__file__), 'plugins')
if os.path.exists(plugins_root):
plugins = os.listdir(plugins_root)
for plugin in plugins:
if not re.match('^__|^\.', plugin):
try:
exec('from plugins import %s' % plugin)
except ImportError:
logging.error('Unable to import %s' % (plugin))
except SyntaxError:
logging.error('Unable to import name %s' % (plugin))


キモは二つ。
  1. os.listdirで特定のディレクトリ以下のすべてのファイル名・ディレクトリ名を取得する
  2. 取得したディレクトリ名を使ってimport文を生成して、exec()で実行する
exec()で無理矢理実行とか正直嫌な感じです。しかしこれ以外に方法はなさそうですね・・・
ファイル名を使ってコマンドインジェクションとかできそうじゃないかと試してみましたが、そもそもファイル名には改行とかバックスラッシュとかが使えないので意外と安全かも。

GAEOでPythonのunittestモジュールを使って単体テストにチャレンジ

■まとめ
site-packagesにインポートするモジュールとかまとめておくのが使うのがいちばん楽


■何がしたいか
以下のようなGAEOプロジェクトがあります。



ここで、test.controller.forecastareaTest.pyにforecastareaモジュールのテストケースを記述するためには、applicationディレクトリにPYTHONPATHを通す必要があります。
それをいちばんスマートにやるにはどうすればよいかいろいろ悩んでました。


■どうしてそこで悩むの?
forecastareaTest.pyは単体で動作させなくてはいけないからです。
もしここで、jweeklyforecastディレクトリの直下にテストケースをおくことが出来るのであれば、
application_root = os.path.join(os.path.dirname(__file__), 'application')
test_root = os.path.join(os.path.dirname(__file__), 'test')
sys.path.append(application_root)
sys.path.append(test_root)

from application.controller import ForecastareaController
from test.controller import TestForecastarea

こんな風に自分のディレクトリからのパスをsys.pathに追加してからインポートすれば一発です。applicationもtestも自分の子供ディレクトリですから楽です。
しかしforecastareaTest.pyの位置から見ると・・・
application_root = os.path.join(os.path.dirname(__file__), '../../../application')
sys.path.append(application_root)

from application.controller import ForecastareaController

こんな風にインポートしなくちゃいけなくなります。相対指定とかする必要があって、ちょっとやな感じです。
PROJECT_HOME = '/User/akisute/DropBox/Projects/GoogleAppEngine/jweeklyforecast/'
application_root = os.path.join(PROJECT, 'application')
sys.path.append(application_root)

from application.controller import ForecastareaController

これでもいいのですが、これだとPROJECT_HOMEが各テストケースごとにべた書きになってしまいます。これまたディレクトリの移動に弱いです。
ディレクトリが動いたらテストケース100件の定数を全部書き直しとか嫌すぎです。


■最終的に出した結論がこれ
site-packagesディレクトリの中にjweeklyforecast_path.pyなる以下のようなモジュールを配置。
#!/usr/bin/env python
#encoding: utf-8
import os, sys

PROJECT_HOME = '/Users/akisute/Dropbox/Projects/GoogleAppEngine/jweeklyforecast'
sys.path.append(PROJECT_HOME)
sys.path.append(os.path.join(PROJECT_HOME, 'application'))

そしてこれを各テストケースからインポート。
するとapplicationディレクトリにパスが通るからインポートして使えるという仕組みです。
#!/usr/bin/env python
#coding: utf-8
import logging
try:
    import jweeklyforecast_path
except Exception, e:
    logging.warn("jweeklyforecast_path not found.")

import unittest
from controller.forecastarea import Forecastarea

class TestForecastarea(unittest.TestCase):
    """Forecastarea test case.
    """
    #以下テストケースがずらずらと続く・・・

ディレクトリが動いたり環境が変わったときには、このjweeklyforecast_pathをsite-packagesにコピーして、中身のPROJECT_HOMEを書き直すだけですみます。


■最後になりましたが
意味不明な記事になってしまってごめんなさい。自分の理解度不足ゆえグダグダになってしまいました><

pythonで、Objective-Cのカテゴリのように、あるクラスのソースを変更せずに任意のメソッドを追加する方法

■結論
すべてのクラスには__bases__という隠しフィールドがあるので、そこに任意のスーパークラスを作って追加する


■何がしたいか
たとえば以下のようなクラスがあります。
class Foo:
def do_something(self, x):
  print x
  return

このクラスのソースコードに指一本触れずに以下のメソッドを追加したい。
  def another_method(self, x, y):
  print x+y
  return

って将軍様が言っていたので、一⑨さんは考えました。


■チーン!ひらめいた!
まずは以下のようにスーパークラスになるクラスを作ります。
class SampleCategory:
def another_method(self, x, y):
  print x+y
  return

そしてここからがポイント。__bases__というTupleに、今作ったスーパークラスのtype型を追加します。
スーパークラスを宣言した後で・・・
from com.akisute.example import Foo
Foo.__bases__ += (SampleCategory,)

これだけです。
なぜかこれでうまくいくのがPythonのふしぎ。

実際のソースコードの例は以下のようになります(以下、拙作のプログラムから抜粋)
#!/usr/bin/env python
# encoding: utf-8
"""Login Authentication plugin.
Extends BasicController to give it an additional function for authentication
using Google account.
"""
import sys
import os

class LoginAuthPlugin:
    def is_login(self):
        """Returns True if requesting user is logged in."""
        #Do some work here
        return false

from gaeo.controller import BaseController
BaseController.__bases__ += (LoginAuthPlugin,)


JavaScriptのprototype書き換えにも似ていますね。
ただしprototype書き換えに比べて優れているのは、__bases__はTupleなので、簡単に好きなだけスーパークラスを追加することが出来ます。
(prototypeだと複数のスーパークラスを追加するのがきわめて困難)
from com.akisute.example import Foo
Foo.__bases__ += (SampleCategory,)
Foo.__bases__ += (AnotherCategory,)


■元ネタ
GAEOでpluginを読み込んでBaseControllerを拡張するときにこのテクが使われていました。
GAEO作った人は凄い。

2009年2月22日日曜日

Mac OS X LeopardでPYTHONPATHとPYTHONSTARTUPを設定してみました

  • 環境変数PYTHONPATHとは、Pythonがimportするときにモジュールを探しに行くパスのこと。JavaでいうところのCLASSPATHにあたる
  • 環境変数PYTHONSTARTUPとは、Pythonを対話モード(プロンプトモード)で実行した時に自動的に実行されるPythonスクリプトのこと。起動時に毎回読み込みたい設定とかを書いておくことができる
  • autoimpとPYTHONSTARTUPを組み合わせるとimportの手間から解放されて非常に便利

Pythonのモジュール名・関数名がわからないときや、ちょっとだけスクリプトを実験してみたいときなどPythonをコマンドラインから呼び出すことがよくあると思います。
ところが未設定のままのPython対話モードだと以下のような問題が生じます。
  • 毎回毎回使うimport osとかimport sysとかをいちいち手で実行するのが面倒くさい。自動でやりたい
  • 後からインストールしたライブラリ、特にGoogle App Engineのモジュールが利用できない
そこでこれらの問題を解決するべくPythonの環境設定を行ってみることにしました。
以下、すべてMac OS X 10.5.6と付属のPython 2.5.1 (Apple Build)で設定を行っています。python.orgからダウンロードしてきたPython 2.6や3.0の場合はファイルのあるパスが違ったりなどするかもしれません。


■PythonPathを通そう
PythonPathとは要するにJavaのクラスパスです。このパスが通っているところからPythonはモジュールをインポートしようとします。
現在のPythonPathを確認するためには、以下のPythonスクリプトを実行します。
>>> import sys
>>> sys.path

似たようなのにos.pathがありますが、アレは全く別物みたいです。まどろっこしいです。

さて、PythonPathを上手に利用するためには2通りの方法があります。
一つは自分で環境変数PYTHONPATHを設定してPythonPathに好きなパスを追加する方法です。
export PYTHONPATH=${PYTHONPATH}:/usr/local/google_appengine:/usr/local/google_appengine/lib/antlr3:/usr/local/google_appengine/lib/django:/usr/local/google_appengine/lib/webob:/usr/local/google_appengine/lib/yaml/lib

もう一つは最初からPythonPathが通っていて、かつユーザーが自由に使ってもいい領域「site-package」を利用する方法です。
詳しい理屈はよくわかりませんが、Pythonには最初からsite-packageとかいう自由にライブラリを追加するための領域があるみたいです。
現在のsite-packageを調べるためには、id:a2cさん曰く
python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

これだけでいいそうです。試しにPython 2.5.1 Apple Buildで実行してみたところ、
$ python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
/Library/Python/2.5/site-packages

こうなりました。たぶんpython.orgのPythonや、macportでインストールしたPythonだとまた全然違った値になるのではないかと。
ということでこの/Library/Python/2.5/site-packages以下に、ダウンロードしてきた外部のライブラリなどを配置していけば自動的にパスが通っていい感じになりそうです。


■autoimpを使ってみよう
autoimpというライブラリを利用すると、いちいち最初にimport osとかimport mathとかしなくても直接os.path.join()とかmath.piとかが呼び出せるみたいです。
http://www.connellybarnes.com/code/autoimp/
使い方は簡単、まずはライブラリのソースを↑のページからダウンロードしてきて、
先ほどご説明したsite-packages以下に置くだけ。

あとは、
>>> from autoimp import *
>>> os.stat('.')
>>> sys.path
>>> math.pi
>>> google.appengine.ext.db.Model

一度from autoimp import *してしまえばimportなしで何でも自由に使えるという寸法らしいです。すごい。
でもこれでは結局最初にfrom autoimp import *と書く手間がかかってしまいますので、
Python起動時に自動的にfrom autoimp import *してくれるように設定してみましょう。


■PYTHONSTARTUPを設定しよう
環境変数PYTHONSTARTUPを利用すると、Pythonの起動時に毎回決められたスクリプトを実行することが出来るらしいです。
たとえば自分のホームディレクトリに、以下の.pythonstartup.pyというファイルを作ってみます。
#!/usr/bin/env python
#coding: utf-8
print 'hogehoge'

そして環境変数PYTHONSTARTUPを以下のように設定します。
export PYTHONSTARTUP=~/.pythonstartup.py

一端ターミナルを再起動してからpythonを実行してみると・・・
akisute ~$ python
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
hogehoge
>>>

ほら、print 'hogehoge'が実行されてますよね。
同様にして、以下のように.pythonstartup.pyを設定すれば・・・
from autoimp import *

Pythonを実行すると・・・
akisute ~$ python
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> os.path
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/posixpath.py'>
>>> math.pi
3.1415926535897931
>>> google.appengine.ext.db.Model
<class 'google.appengine.ext.db.Model'>

ごらんの通り!importなしに自由にモジュールが利用できています!

2009年2月15日日曜日

jweekyforecast近況報告(2009/02/15)


ようやく予報区のマスターメンテができるようになりました。
天気予報区のデータをアプリケーションに登録して、それをAPIを通じてiPhoneに引き渡すというような処理を行おうと思っています。


天気予報区には大きく分けて一次細分区域と二次細分区域がありますが、今のところ一次細分区域しか対応していません。二次細分区域を対応させようと思ったら親子関係を持たせないとなぁ。

何より問題はこのマスターメンテが死ぬほど面倒くさいことかなぁ・・・と思います ;(

さてさて、次はAPIを作らないとシステムとして成り立たないですね。