Pythonの文字列メソッドの罠

うわあ...これはUnicodeですね。

業務で、「与えられた文字列が半角英数で構成されているかを判定したい」という場面に遭遇した。 これはユーザーに何かを入力させる際にその文字列が想定しているものなのかを調べるケースの典型例である。 Pythonの場合、正規表現を書くまでもなく文字列のメソッドで判定ができる、と思っていた。 次のようなユニットテストを書いていた。

import unittest

class UtilsTest(unittest.TestCase):

    def test_is_alphanumeric(self):
        """与えられた文字列が半角英数で構成されているか"""
        cases_is_ok = ("12334567890", "abcxyz", "ABCXYZ", "abc123XYZ")
        cases_is_ng = ("3.141592653589793", "たまげたなあ", "０１２０ー０２２−０２２", "0790-62-0110")
        for case in cases_is_ok:
            with self.subTest(case=case):
                self.assertTrue(case.isalnum())
        for case in cases_is_ng:
            with self.subTest(case=case):
                self.assertFalse(case.isalnum())

余裕で通ると思っていたユニットテストに失敗してしまった。どうしてだろうか。

いつから「半角英数」の「英」がアルファベットだと勘違いしていた...？

まずは、str.isalnum()のドキュメントを調べてみよう。

str.isalnum() 文字列中の全ての文字が英数字で、かつ 1 文字以上あるなら真を、そうでなければ偽を返します。文字 c は以下のいずれかが True を返せば英数字です: c.isalpha() 、 c.isdecimal() 、 c.isdigit() 、 c.isnumeric() 。

なるほど。あやしいと踏んだstr.isalpha()のドキュメントを調べる。

文字列中の全ての文字が英字で、かつ 1 文字以上あるなら真を、そうでなければ偽を返します。英字は、Unicode 文字データベースで "Letter" として定義されているもので、すなわち、一般カテゴリプロパティ "Lm"、 "Lt"、 "Lu"、 "Ll"、 "Lo" のいずれかをもつものです。なお、これは Unicode 標準で定義されている "Alphabetic" プロパティとは異なるものです。

なんということだ、str.isalpha()の英字とはUnicode 文字データベースで "Letter" として定義されているものなのか。

>>> import unicodedata
>>> unicodedata.category("た")
'Lo'

ひらがなは "Lo" 、つまりLetterでOther Letterのカテゴリに属しているようである。 たまげたなあ。

対策

1つは正規表現を書くことである。

>>> import re
>>> re.match(r"^[0-9A-Za-z]+$", "たまげたなあ") is None
True

Python 3.7以降はstr.isascii() メソッドが追加されているので援用できる。

>>> "たまげたなあ".isalnum() and "たまげたなあ".isascii()
False

Unicodeに強くなりましょう。

『アジャイルイントロダクション』を読んだ。

アジャイル開発の利点・誇張・難点

近代科学社から発売されているトップエスイーシリーズの入門講座の2分冊目である『アジャイルイントロダクション Agile開発の光と影』を読んだ。

www.kindaikagaku.co.jp

www.kinokuniya.co.jp

Twitterで見かけたのがきっかけである。 最初はそこまで気にしていなかったが筆者がオブジェクト指向プログラミングの本で有名なBertrand Meyerであることに気づいた。 面白そうな予感がしたので購入してみた。

原著のタイトルは『Agile! The Good, the Hype and the Ugly』と（監修者も認識しているが）「光と影」よりも細かい。 原著の表紙の方がオシャレで好きなのだが、トップエスイーシリーズで表紙を揃える必要があるので仕方がないか。

www.springer.com

原著はSpringerであり、まともに原著を買おうとすると5000円近くするので邦訳の方が1000円程度安く、かつ簡単に入手できる。

内容は、端的に言えば従来のソフトウェア工学の観点からアジャイル開発と呼ばれる手法を冷静に分析したもの、である。 その分析の結果としての利点・誇張・難点のカテゴリに分類している。 具体的に何が難点なのか、などをずらずら書くと読む楽しみがなくなってしまうので詳細は避けるが、アジャイル開発の事前のドキュメント作成軽視を批判的に扱っているなど、 アジャイル開発信奉者ではない、けれどもアジャイルを深く研究した筆者の冷静な分析は是非読んでみてほしい。 アジャイル開発を宣伝する本はたくさん存在するが、学術的な側面から分析した本（特に、日本語で書かれているもの）は貴重である。

トップエスイーやらトップエスイーシリーズが何者なのかよくわかっていないが、トップエスイーシリーズの他の分冊の評判が知りたい。

『入門 監視』を読んだ。

さくっと読めて考えるべきポイントが掴める本

オライリージャパンから出版された『Pratical Monitoring』の翻訳である『入門 監視』を読んだ。

www.oreilly.co.jp

発売される前からそのシンプルかつ「なぜモニタリングではなく監視なのか」という疑問が湧くタイトルで興味を持っていた。 今回、いつもお世話になっている編集の方からご献本いただいたので、かつ、せっかく読んだので記録を残していこうと思い、このエントリを書く。

面白かったポイント

面白い観点は、5章の「ビジネスを監視する」である。 従来、監視というとOSのメトリクスやヘルスチェックなどシステム寄りの監視ことしか頭になかった。 ビジネスのメトリクスという観点は非常に面白く、現在自分が関わっている案件でも取り入れることができないのか考えてみたい。

ちょっと気になったところ

本書では「デザインパターン」という用語をクリストファー・アレグザンダーが提唱した「パタン・ランゲージ」の文脈ではなく、単なる「よいやり方」という意味で使っていることが多少気になった。もっとも、この指摘は「デザインパターン」という用語の定義を厳密に考えようとするとひっかかるに過ぎず、「よいやり方」でも十分面白い内容である。

最後に

よく手にする技術書は300ページやら500ページなど重厚な本が多い。 この『入門 監視』はサイズがA5判で200ページとコンパクトである。 では中身が薄いか、というと、もちろんそんなことはなくさくっと読めて考えるべきポイントが掴める本である。 特定のツールの使い方ではないので、あと数年は役に立つ内容である。

監視は全員がやるべき仕事であり、チームや部署内での役割ではありません。

とあるように、全員が読む本である。 ぜひ買って読んでほしい。

蛇足

A5判で200ページとコンパクトな本だとすぐに読めて嬉しいのでオライリージャパンからこの手の本がたくさん出てほしい。