月: 2012年5月

今週知ったこと。走ってる Python インタプリタの unicode 内部実装が narrow (16bit UCS-2) か wide (32bit UCS-4) かを知る方法: sys.maxunicode を見る。

ucd.py 0.5.0 を公開。今週できたとこまでの中間報告という感じ。来週もやるよー。

こまごまと進めていったら、sentence break とか分割をカスタマイズ可能にするとか、面倒だと思ってたところができてしまったのでちょっと嬉しい。

そろそろモジュールの名前を変えたい。ucd というのは、Line_Break 属性を返す関数などがあるので最初は unicodedata モジュールに近いものかと思って “Unicode Character Database” からとっていたもの。しかしだんだん方向性が見えてきて、違う名前のほうが相応しいような気がしてきた。いま思ってるのは、これは文字列をいろいろな境界で分割する機能（segmentation）を提供しているものと言えるので、textseg か uniseg なんてどうかな、と。UAX #29 も “Unicode Text Segmentation” だしね（UAX #14: Unicode Line Breaking Algorithm とかも扱ってるけど）。あと ucd.codepoint とかのサブモジュールは廃止予定。廃止というか、ルート・パッケージでぜんぶ import してしまう。関数名が長くなって取っつきにくい。

更新情報

こないだぶつぶつ言ってた件、思いきって手を入れたので公開することにしました。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 用の折り返し処理にも使えるクラスを内蔵してまして、それもこの先ブラッシュアップしていきたいんだ。

このモジュールを前提にできると、この先他のテキスト処理のライブラリが作り＆公開しやすいのだけどなあ。

今年のゴールデンウィークはどこに行くともなくて、家や近所で本を読んだりコード書いたりしてた。

私用でいろいろと使っている Python のモジュールを整理して公開したいのだけど、その整理がどうもうまくまとまらない。仮名とか漢字とかを扱うデータベース的なものが多いんだけど、たいてい Unicode 文字列と真面目に取り組まないといけないことになる（とくに JIS X 0213:2004 以降に対応しようとすると）。で、そのために unicode オブジェクトを適切に分割するとか数え上げるとかするようなサブモジュールを作ることになる。とりあえずその部分だけ公開しようとしたのが、codepoint.py です。

でもこれだけだと物足りないこともあるね。たとえば JIS X 0213 では半濁点のついたカ行の仮名や小書きの「プ」などが追加されてるんだけど（主にアイヌ語の表記のためだと思う）、これらは Unicode では単独のコードポイントには割り振られていなくて、「仮名文字、U+309A」という、ふたつのコードポイントの組み合わせで表すことになっている（それでこれまでの JIS では保たれていた Unicode とのコードポイントにおける一対一の対応関係というのが崩れたと非難されたりもした）。こうした文字を含む文字列を列挙 (iterate) するときには、コードポイント単位での分割では不十分である。

Unicode では最小の区分単位であるコードポイントの上位に、「利用者が一文字と認識している区切り」にほぼ等しいものとして、grapheme cluster という区分が定義されている。上記のような文字列はこのグラフィム・クラスタ単位で分割して処理しなければいけないわけです。ほんとは。

で、そういうユーティリティ的なものをどうまとめるかが悩みどころで、本来の目的のモジュールのサブモジュールに入れてしまえば依存関係がなくなるから楽なんだけど、グラフィム・クラスタ云々までやるとけっこうコードが大きくなって、それだけでモジュールにしたほうがよさげになる。じゃあ独立させればとなるんだけど、独立させるとその上の単語区切りとか禁則とかのことも扱うモジュールであることを期待されるような気がして話がでかくなる（本来のモジュールのほうに手が回らなくなりそう）。あーどうしよう、というのをもう数年悩んでる。数年悩んでたら unicodedata モジュールが標準で対応してきてるんじゃないのと思ったけどまだ対応してこない。

でもここに書いてたらちょっとやる気になってきたよ。やるかも。ていうか前にここで出したことあるっけ？　まあいいか。ツイッターだと字数制限あるしこういう悩みは書けなかったんだよねー。