EmptyPage.jp > Whining Express > 2012-05-20
サイトの更新情報や日々の雑感など。
こないだぶつぶつ言ってた件、思いきって手を入れたので公開することにしました。Python で Unicode 文字列を分割したりするモジュールです。で、その一部だった codepoint.py は引っ込めた。短い命であった。
というか、これ一回公開してますね。おととしのいまごろ、今とおんなじようなぐだぐだしたテンションで。この時は uniwrap.py がメインで ucd はそれに必要なモジュールという感じで書いてる。
その後このモジュールはあんまり触ってなくて、でも ucd.codepoint の部分はけっこう使い回してて、なんかずるずると依存していたのだった。今回気を取り直してごっそり見直してコードを整理しました。
データベース部分に組み込みの sqlite3 モジュールを使うようにしました。遅くなってるような気がする(前はデータから Python コードを直接生成していた)けど、unicode.org のサイトで公開されてるデータから完全に機械的に流し込んでいるので、この部分で余計な心配をする必要がないのは開発途上の今の段階ではいいかな、と。
UAX #29 で定義されてる、文字(グラフィム・クラスタ)単位と単語単位の分割は完全に実装できてます。ユニット・テストは unicode.org のテスト用データから自動生成してテスト・ケースにしてるので、これはたぶん大丈夫。ものすごく愚直に落とし込んだコードなので、遅いけど、動いてます。速くするのはこれからテスト逸脱しないようにやっていけばいいよね。
で、問題は UAX #14 の行分割のほう。いわゆる禁則処理に相当するんですけどね、前にツイッターでぶつぶつ言ってたような気がするけど、この Technical Report に提供されてるテスト用データ(LineBreakTest.txt)がどうもバグってるらしいのね。前はそれで unicode.org メーリングリストにまで書いて訊いたのだった(そこで言われた)。だから、せっかくここからテスト・ケースを生成してもテスト側が間違ってたりするから必ず失敗する。これの開発にいまいちのめり込めなかったのはこのぐだぐだのテスト・データのせいだっ。
今回これもより愚直で馬鹿正直な(遅い)コードにしたおかげか、それでもテストのほとんどは通るようになっている。5202 件あって失敗は 17 まで減った(ucd/linebreaktest.py をスクリプトとして実行すると ucd/linebreak.py 用のユニット・テストを実行します)。失敗内容を見ると、件のテスト側が間違っているっぽいのがほとんどで、微妙な(どっちが間違っているのか仕様をよく読んで考える必要がある)のが数例という感じ。
uniwrap.py という折り返しスクリプトを(今回も)付けてるので遊んでみてください。あと、このスクリプトは GUI 用の折り返し処理にも使えるクラスを内蔵してまして、それもこの先ブラッシュアップしていきたいんだ。
このモジュールを前提にできると、この先他のテキスト処理のライブラリが作り&公開しやすいのだけどなあ。