Pages

June 28, 2012

ネタが無くなった

cchardetを作るまではいろいろはかどっていたプログラミングですが、それを終えるとネタがないことに気づいた。

PyGooglePlusは仕様変更の速度についていけないのとサンプリングデータの数が少ないのでという理由であまり更新できない。

もっとも仕様変更に柔軟に対応できるプログラミングの仕方が考えつかない自分のせいでもあるのですがXD


なにぶんニートの身分だと、やることがないと暇なのである。

仕事探せというお話ではあるのですが、仕事を探すのがひどく億劫。どうしようもないクズである…

親には申し訳ないとは思うけれど、もうちょっと自由でいたい反面、お金がないと遠征もできない。

素晴らしい負の連鎖である。 バイトくらいは探したほうがよさそう。

June 26, 2012

cChardetをPyPiに登録してみた

BeautifulSoupのGoogle Groupにcchardetを導入したら高速化したよって報告したらBS開発者から

「ビルド等の導入をシンプルにしてくれたら使ってやってもいいよ。」

と言われたのでlibcharsetdetectを取り込んで1つの静的ライブラリにしちゃいました。

いくつかライブラリを作っているみですが、PyPiにはじめて登録しました。

適宜setup.pyに必要な情報を入れたら、

$python setup.py register
でユーザ登録とライブラリの登録を済ませます。その際にログイン済みでないとファイルのアップロードができなくなりますので注意してください。

そして、sdistをアップロードさせます。
$python setup.py sdist --formats=gztar upload

これだけで簡単に登録できちゃいました。 難しいこと考えずにアップロードできるのは大変便利ですね。

ただし、registerすると~/.pypircにユーザ名と暗号化されていないパスワードが書かれちゃっています。

registerでログイン・アップロードを終了したら消すという作業をするのもありなのかもしれませんね。

この辺は要調査

cchardet: PyPi

June 20, 2012

より高速なchardet、cchardetをリリースしました

以前の投稿にchardetがあまりにも遅いと嘆いていました。

これも何かの縁だと思い、Cythonの練習がてら、さっそくcchardetをリリースさせて頂きました!

ベンチを取ったのですが、C拡張なだけあってかなり早い結果が出ました。

chardetが4.009999990463257秒で検出したのに対し、cchardetは0.0009999275207519531秒と実に4000倍!(計算あっているか不安w)

割かし満足しています。

ただ不満もありまして、chardetはconfidenceを出力できるのに対し、cchardetはencodingしか吐きません。

これはcharsetdetectライブラリ側の問題なのですが、いずれソースをいじって得られるようにしたいと考えています。

もう1つはビルド環境がWindowsでしかおこなっていないため、setup.pyをもう少々柔軟なものに変えないと他のプラットフォームで扱えないことです。

この2つは時間があるときに修正していきたいと思います。

ではでは

PyYoshi / cChardet

追記 2012,06/20,22:39
linuxもビルドできるように修正しました。 Ubuntu 12.04 64bit環境で確認

追記 2012,07/07,14:35
confidenceを取得できるようにしました。


June 18, 2012

PyGooglePlusをプロファイリングしてみた

現在noseでテストコードを書いてるのだけれど、ついでにどこが足を引っ張っているのか知るためにnose経由でプロファイリングしてみた。

準備
  • Graphizをインストール
  • $ pip install https://guppy-pe.svn.sourceforge.net/svnroot/guppy-pe/trunk/guppy
  • $ pip install pbp.scripts

テストコードをtests.pyとして書いたら
$ nosetests --with-profile --profile-stats-file nose.prof tests.py
$ hotshot2dot nose.prof| dot -Tpng -o profile.png
を実行して出力した画像とにらめっこ

今回はApiHandler.get_user_info()のみのテストコードで行った。 またBeautifulSoup4がリリースされていることを知り、lxmlあれば早くなるよって言ってたので、3と4の2パターンで行った。

以下が結果である。







上がBS3、下がBS4であるが結果としては、lxmlを使っているはずのBS4のほうが遅い結果になっている。処理が余計にかかっている印象。 いずれ改善されると思うけど、特に必要性を感じないのであればBS3を使っておけばいいと思う。

それにしてもchardetの処理が足を引っ張りすぎている気がする。それと自分のライブラリ(苦笑)

※ この結果を出したときは指定していなかったが、文字コードが固定で既知なら,from_encoding引数をBeautifulSoupに指定してあげるのもいいと思うよ。 実験的にPyGooglePlusにも使用してみたら、5分の1くらい処理時間が縮まりました。 省いてるから当然だね。 だとしてもC拡張のchardetが欲しくなるよね。だれか作らないかな

参考:



June 05, 2012

Pythonコードを実行ファイル(exe)にするときの注意点

自分が知っている限りだと、py2exeとcx_freezeがある。前者はwindowsのみ対応であるが、cx_freezeはmac等のプラットフォームにも対応している。

さらにcx_freezeはsetup.pyに特に記述しなくても実行ファイルを作ることができるのでpy2exeより手軽に作れて便利なのである。

またpy2exeに比べてコードの依存関係のチェックを詳しくしているのか実行ファイルサイズが小さくなる

で、便利ではあるcx_freezeなのだが使ってみて デメリット が2つほどあった。

1. py2exeでは1ファイルのなかにpydやpython.dll等があるのだが、cx_freezeは実行ファイルの他にpydとかそのへんの動的ライブラリが外に出る。

2. py2exeはバイナリにビルドするコードを内包しているが、cx_freezeは__main__.py*というファイルにもろでているため、ごにょごにょするとバイトコードの中身がわかってしまう。

というデメリットがある。 #1のデメリットはNSISを使えば1ファイルにまとめ上げることは出来る。 (参考)


以下のことから、あんまり見せたいくない文字列があるときはcx_freezeは避けて、py2exeを使えばいいのである。

その時は

1. なるべくコードは1ファイルに収めてビルドする。

2. 見せたくない文字列がある場合は軽く難読化する。

に気をつければいいんじゃないかな?

※ py2exeのメインコードは実行ファイルのバイナリでしか見つからなかったが、どこか違う場所にあるかもしれないので、この記事自体が意味をなさなくなるかもしれないのであしからず。

それと、そもそもPythonという言語のコンパイルはバイトコードに変換するだけであってC#とかJavaのように中間コードに変換しているわけではないので、コードは覗かれて当然であるという認識のもとで使うべきであるかと思います☆(ゝω・)vキャピ

June 01, 2012

IronPythonはクソ

PyGooglePlusでクライアントでも作ろうかとC#にIronPythonを組み込んで実験していたのだけれど、どうもうまく動かない。

というのもIronPython単体ではCPythonには負けるものの、いちよ実行はできたのだけれどC#から呼ぶとログイン処理からユーザ情報取得処理までに5分くらいかかる始末

せっかくdynamic使えてかなり親和性が上がっているのにもったいないなぁ…

ちなみにurllib2までの処理は軒並みな速さなのだけれどObjectを生成するBeautifulSoupやsimplejsonでかなり時間がかかっているみたい。

というわけで、pythonで書かれたものをrpc serverにしてソケット通信すればいいんじゃね?ってのが昨日たどり着いた結論;(