edvakfのブックマーク - はてなブックマーク

s.decode('utf8') よりも unicode(s, 'utf-8') の方が速い - methaneのブログ
http://groups.google.com/group/comp.lang.python/browse_thread/thread/314a3043ea63319f/ unicode vs s.decode unicodeはLOAD_GLOBALで、s.decodeはLOAD_ATTRでスタックに積まれる。で、LOAD_GLOBALの方が速い。さらに言えば、何度もデコードを行うのであれば u = unicode のようにローカル変数にするとさらに速くなる。LOAD_ATTRやLOAD_GLOBALは最適化で消すことが出来ないので、明示的にローカル変数に束縛することはCPythonに限らず有効な手法だ。 'utf8' vs 'utf-8' 単なる1タイプの問題だけど、内部的には 'utf-8' が利用されており、 'utf8' を使うと 'utf-8' だと判断するのに1クッション必
edvakf 2009/08/17
python
リンク
','.join() がなぜキモイのか - methaneのブログ
Ruby厨とPython厨が平行線の議論をしていたので、まとめてみる。オブジェクト指向的にキモイ? str.join() 処理での登場人物は2人いる。連結文字(区切り文字=separator)、連結される文字列の列だ。この二つを比べると、「連結される文字列の列」が情報的に重要な場合がほとんどだろう。それを元に文字列の列が主役で連結文字はオマケと考えると、「joinが主役でない連結文字側のメソッドになる何てキモチワルイ」となる。でも、別の視点で「連結する側とされる側」というように分類すると、「区切り文字 join 連結される文字」が素直な能動態で、「連結される文字列 (is) join(ed by) 連結される文字」だと無理やりな受動態になるので、''.join() の方が素直だ。 Rubyの場合は「配列が要素をjoinする」と配列が主体となっているので、後者の考え方はしにくい。なので
edvakf 2009/06/15
ruby

python
リンク
Pythonプログラムがメモリを大量に使っているとき - methaneのブログ
もし想定以上のメモリを Python プログラムが消費しているのであれば、ループの中で循環参照が生まれていることや、回収不能オブジェクト(循環参照なうえに __del__ メソッドが存在するためにgcがどこから循環を切っていいのか判らないオブジェクト)が存在しないかを疑う。 import gc gc.set_debug(gc.DEBUG_LEAK) gc.disable() # 問題の処理 gc.collect() # 回収された循環参照や回収不能オブジェクトが表示される
edvakf 2009/06/02
python
リンク
1