lxml.objectifyの問題

メソッドとタグ名が同じだとタグ名でタグにアクセスできない。
他のライブラリGnosis objectifyやBeautifulSoupでも同じようにアクセスできない。
Gnosis objectifyはメソッド自体がほとんどないのでそれほど気にする必要はないと思う。
Amaraは同じ名前があると_タグ名でアクセスできる。
BeautifulSoupやlxml.objectifyを使ってアクセスする場合はメソッド名をすべて把握して重複する時は、xpathやfindなど別の方法でアクセスする必要がある。
もしかするとAmaraのような回避方法があるかもしれないが調べてない。

BeautifulSoupの最新版

BeautifulSoupの最新版がLunchpadで公開されていたが大幅に変更されていた。
(LunchpadはBazaarを入れないとソースがダウンロードできなかったはずなのであまり好きではない。
Bazaar自体もローカルでコミット出来るサーバ型なのであまり好きではない。まともに実用できるsvkみたいなイメージがある。)
これまでBeutifulSoup.pyだけだったのが複数ファイルになり、その上lxmlを利用できるようになっていた。
パース時の速度がかなり遅かったのでこの変更は期待できるかもしれないがlxmlを利用してもそこ以外が遅ければまったく意味がない。
個人的にはxpathを使うよりBeautifulSoupの方が目的の要素を探すのが楽だから期待はしている。

chameleon.genshiが速い

chameleon.genshi

Genshi template 665.46 ms
Mako Template 102.64 ms
Djange template 784.00 ms
Spitfire template 87.78 ms
Spitfire template -O1 54.63 ms
Spitfire template -O2 23.70 ms
Spitfire template -O3 23.22 ms
Spitfire template -O4 14.42 ms
StringIO 113.35 ms
cStringIO 25.57 ms
list concat 20.83 ms
ChameleonGenshi 114.44 ms
ChameleonZPT 121.35 ms

spitfireに付属していたbigtable.pyにchameleon.genshiとchameleon.zptを追加して計測。
ただしspitfireのサイトにあるベンチマークの結果に比べてchameleon.zptが遅いのが気になる。

あとgenshiとどれくらい互換性があるのかわからないが普通に使う分にはとくに問題はなかった。
ただし改行の仕方がまったく違うのでその点は注意する必要がある。

makoとほとんど速度が変わらないのでこれまでxmlベースのテンプレートは遅いという理由でgenshiを避けてた人は
chameleon.genshiを使えば速度の問題は回避できそう。

どうでもいいけどspitfireの速さは異常。いくらpsycoを使っているとはいえ、一行ごとリストを追加するより速いとは。

win32mbcs-patch更新

最新だとパッチが当てれなかったので更新

pythonの次期VCSがMercurialに決定

http://mail.python.org/pipermail/python-dev/2009-March/087931.html

>The decision is made! I've selected a DVCS to use for Python. We're
>switching to Mercurial (Hg).

bazaarはブランチを扱うのが面倒だったりするので、
GitかMercurialになればいいなあと思っていました。

正式にmercurialへの移行が決まったことは今自分が使っていることもあり、良かったと思います。