正規表現リテラルは本当に必要なのか？

正規表現リテラルは
本当に必要なのか？
Makoto Kuwata
kwa@kuwata-lab.com
http://www.kuwata-lab.com/
copyright© 2014 kuwata-lab.com all rights reserved
PyConJP 2014
ver 1.1 (2014-09-17): スライドを追加・加筆

発表の背景
✓ 2013年末、プログラミング言語における「正規
表現リテラルの必要性」が支持を集める
http://togetter.com/li/603521
http://blog.kazuhooku.com/2013/12/blog-post.html 　
✓ Pythonは正規表現リテラルがないけど、別に困
ってないよ？
…と説明しても聞いちゃくれないPerler/Rubyist/JavaScripterと、
正規表現リテラルがなくて困ってるJavaユーザと、どんなときでも
叩かれるPHPerが入り乱れた、異種言語間お笑いバトル

え|マジ
正規表現
リテラルないの？
あれなしで許されるキモ|イ
のはPHPまでだよね！
キャハハハハハハ
Pythonの評判

発表の目的
✓ 正規表現リテラルは、あれば便利だけどなくても
困らない（ライブラリでカバーできる）ことを説
明する
✓ Pythonの正規表現ライブラリが抱える問題点と
その解決案を紹介する

発表の対象者
✓ Pythonのことをよく知らないPerlerやRubyist
やJavaScripter　
✓ 他言語との違いが気になるPythonista
✓ 二重バックスラッシュにイライラしてるJavaユー
ザ

第1部：
正規表現リテラルに関する誤解

第1部：正規表現リテラルに関する誤解
✓ 誤解：正規表現リテラルがあったほうが書きやすい
✓ 誤解：正規表現リテラルがあったほうが性能がよい
✓ 誤解：正規表現のほうが文字列関数より学習コスト
が低い

正規表現リテラルがあると、正規表現は書きやす
い？
## 正規表現リテラルあり
/[a-z]+/.exec(string) # JavaScript
## 正規表現リテラルなし
(new RegExp("[a-z]+")).exec(string) # JavaScript

正規表現リテラルがなくても、正規表現を書きやす
くできる
function re(pattern) { # JavaScript
return new RegExp(pattern);
}
re("[a-z]+").exec(string)
関数やライブラリで解決できる

二重バックスラッシュ問題を発生させないためには
正規表現リテラルが必要？
## 正規表現リテラルあり
/^dd:dd$/ # JavaScript
new RegExp("^dd:dd$") # JavaScript

raw文字列リテラル (Python) やシングルクォー
ト(JS, PHP)でも発生しない
## JavaScript
new RegExp('^dd:dd:dd$')
## Python
re.match(r"^dd:dd:dd$", timestr)
## PHP
preg_match('/^dd:dd:dd$/', timestr)

ただしraw文字列相当のない言語、お前はダメだ
## Java
import java.util.regex.Pattern;
import java.util.regex.Matcher;
Pattern pat = Pattern.compile("^dd:dd$");
Matcher m = pat.matcher(timestr);
二重バックスラッシュが辛いです ;(

【問題点】
Javaで正規表現が書きにくい
（二重バックスラッシュがつらい）
【解決策】
正規表現リテラル
【解決策】
raw文字列リテラル
導入すると、言語仕様が
肥大化してしまう
正規表現以外にも利用可能、
かつ言語仕様が肥大化しない

とはいえ、raw文字列リテラルを導入するには
言語仕様の拡張が必要
## Java
Pattern pat = Pattern.compile(r"^dddd$");
Matcher m = pat.matcher(input);
raw文字列リテラルがほしいけど、
言語仕様を拡張しないと無理じゃん ;(

そもそも、バックスラッシュでないとだめなん？
## 先行事例: Cのprintf()やJavaのString.format()
String.format("s=%s, n=%d", s, n);
メタキャラクタとして「%」を使っている！
二重バックスラッシュのような問題がない！

バックスラッシュ以外を使えば、Javaでも正規表
現が書きやすくなる！ (最初は違和感あるけど慣れの問題)
## http://kwatch.houkagoteatime.net/blog/2013/12/28/java-regex/
import static benry.rexp.Rexp.rexp;
import benry.rexp.Matched;
String pat = "^(`d`d`d`d)-(`d`d)-(`d`d)$";
Matched m = rexp(pat).match(str);
if (m != null) {
System.out.println(m.get(1));
}
「」のかわりに
「`」を使ってる
（変更も可能）

【問題点】
Javaで正規表現が書きにくい
（二重バックスラッシュがつらい）
【解決策】
バックスラッシュを
やめる
【解決策】
正規表現リテラル
【解決策】
raw文字列リテラル
言語仕様の変更が必要なく、
ライブラリだけで実現可能

✓ 正規表現リテラルのないJavaでは、
正規表現が書きにくい
✓ 正規表現リテラルのあるPerlやRubyでは、
正規表現が書きやすい
✓ だから、プログラミング言語に
正規表現リテラルは必要だ！
・問題：解決方法＝ 1：N
(*注)
・one of themでしかない方法を、only oneな方法だと勘違いしてる
(*注) もちろん、複数の解決方法の間では優劣が存在する。この場合なら、「正規表現リテ
ラルが必要」と主張するには、それが他の方法より優れていることを説明する必要がある。
← わかる
← わかる
← その理屈はおかしい

ここまでのまとめ
✓ 正規表現を書きやすくする言語機能は、ひとつで
はない
正規表現リテラル、raw文字列リテラル
✓ 正規表現リテラルよりraw文字列リテラルのほう
が望ましい
正規表現以外にも利用可能だし、言語仕様も肥大化しない
✓ そもそも、バックスラッシュを使わなければいい
言語仕様の拡張が必要ないので、今すぐ使える方法

正規表現リテラルなら、コンパイルは1度だけ
## Ruby
100.times do
filename =~ /.(png|gif|jpe?g)$/
end
100回コンパイルされたりはしない
(ただし埋め込み式のある場合は別)

正規表現リテラルがない場合はどうなる？
## Python
for _ in range(100):
re.search(r'.(png|gif|jpe?g)', filename)
re.search() の中で毎回コンパイル
されてそうだから、遅いのでは？

ライブラリがキャッシュすれば無問題
## Python
_cache = {}
def _compile(patstr):
## キャッシュがあればそれを返す
try:
キャッシュを活用
return _cache[patstr]
except KeyError:
pass
## なければコンパイルして
## キャッシュする
pat = sre_compile(patstr)
_cache[patstr] = pat
return pat
def search(patstr, s):
pat = _compile(patstr)
return pat.search(s)
def sub(patstr, rep, s):
pat = _compile(patstr)
return pat.sub(rep, s)
注：実際の正規表現ライブラリ (re.py) では、正規表現フラグつきでキャッシュしたり、
キャッシュが大きくなりすぎるとパージするなど、もっと複雑である。
他の関数は _compile()
を呼び出す

どうしても気になる場合は、正規表現オブジェク
トを変数で保持すればよい
## Python
rexp = re.compile(r'.(png|gif|jpe?g)')
for _ in range(100):
re.search(rexp, filename)
キャッシュから取り出す
オーバーヘッドがなくなる
（通常は気にするほどではない）

なおCPythonでは、正規表現ライブラリより
文字列関数のほうがかなり速い
startswith()
endswith()
isdigit()
文字列関数正規表現
文字列関数の速度を100
としたときのグラフ
https://gist.github.com/kwatch/f923fb5a71da3f69eccb
https://gist.github.com/kwatch/0132268e0c38741fe59a
https://gist.github.com/kwatch/e1bc95fcc6cb75c60c94

また正規表現に対する高度な最適化は、リテラル
の有無ではなく、処理系の評価戦略次第
// Rust (http://doc.rust-lang.org/regex/)
#![feature(phase)]
#[phase(plugin)]
extern crate regex_macros;
extern crate regex;
正規表現文字列をコンパイル時に評価
→ 正規表現リテラルがなくても
コンパイル時に間違いを検出
→ 正規表現リテラルがなくても
バイナリを生成可能
fn main() {
let re = regex!(r"^d{4}-d{2}-d{2}$");
assert_eq!(re.is_match("2014-01-01"), true);
}

✓ キャッシュを使えば、正規表現が毎回コンパイル
されることはない
正規表現リテラルがなくても充分な性能は出せる
✓ 正規表現より文字列関数のほうが高速
少なくともCPythonではそう
✓ リテラルがなくても正規表現のコンパイル時評価
は可能
「リテラルの有無」と「処理系の評価戦略」は、基本的に別個の話

✓ そもそも、「正規表現リテラルは必要か？」と
「正規表現と文字列関数はどちらが学習コストが
低いか？」は別の話
仮に「正規表現のほうが文字列関数よりわかりやすい」という結
論になったとしても、それをもって「正規表現リテラルは必要」
とはならない
✓ そのうえで、あえて「どちらが学習コストが低い
か？」を論じる。

文字列関数で済む範囲であれば、正規表現より
文字列関数のほうが読みやすい、わかりやすい
## 正規表現
re.match(r"^d+$", input)
re.match(r"^http://", string)
re.search(r".(png|gif|jpg)$", filename)
毎日コード書いてる人なら
覚えられるだろうけど・・・
## 文字列関数
input.isdigit()
string.startswith("http://")
filename.endswith((".png", ".gif", ".jpg"))
初級者でもわかりやすい！

また正規表現は落とし穴も多いので、初級者には
つらいことも
## Ruby
string =~ /.html$/
厳密には間違い
（正解は /.htmlz/ ）
## Ruby
string.end_with?(".html")
初級者でも間違えない！

とはいえ、上達するにつれ、正規表現を避けるこ
とはできない
## 正規表現
pat = r"^(d{4})-(dd)-(dd)[ T](dd):(dd):
dd)$"
re.match(pat, input)
文字列関数でこれを書くのは
つらい

学習コストの内訳（ソース：個人的印象）
文字列関数
正規表現の学習コストに比べたら、
文字列関数のそれは大したことない
（単機能ばかりだから）
正規表現正規表現
正規表現だけ正規表現+文字列関数

コア言語仕様を肥大化させて
でも文字列関数を減らすこと
がそんなに重要なの？
それ正規表現リテラル
じゃなくて正規表現の
メリットじゃないの？
“正規表現リテラルがあれば
文字列関数を減らせるし、
処理系も単純にできるよ！”
誰にとってのメリットなの？
ときどきしかコードを書かない
ライトユーザにも嬉しいことなの？
(科学者、統計学者、CGデザイナ、etc)
そんな簡単な話ではないはず・・・
「/..../」のパースは単純なの？
文字列関数が減るかわりに
別の複雑さが増えてない？

✓ 文字列関数だけのほうが学習コストは低い
学習コスト：正規表現＞＞＞文字列関数
✓ とはいえ正規表現の勉強はどのみち必要
学習コスト：正規表現＜文字列関数＋正規表現
✓ 正規表現やリテラルの得失は一概には言えない
だれにとってのメリット？どのくらいのメリット？
✓ そもそも「正規表現リテラルの得失」と「正規表
現の得失」は別の話
ちゃんと分けて議論しましょう

第2部：
Python正規表現ライブラリの
問題点と解決案

第2部：Python正規表現ライブラリの
問題点と解決案
✓ re.match()とre.search()の2つがある
✓ ライブラリの使い方が2系統ある
✓ 正規表現がいつもキャッシュされてしまう
✓ 連続したマッチングとif文との相性が悪い

re.match()は先頭からのマッチングしかできない、
re.search()なら途中からのマッチングも可
## これはマッチする
re.match(r"(d+)", "123abc")
re.search(r"(d+)", "abc123")
## これはマッチしない！（先頭にないので）
re.match(r"(d+)", "abc123")
re.match(r"pat", str) は re.search(r"^pat", str) で代用できる。
re.match() は混乱のもとだし、いらないのでは？

追加スライド
Pythonの正規表現ライブラリは、使い方が2系統
存在する
re.compile().xxxx() 系re.xxxx() 系
大抵の正規表現操作が、モジュールレベルの関数
と、コンパイル済み正規表現のメソッドとして提
供されることに注意して下さい。関数は正規表現
オブジェクトのコンパイルを必要としない近道です
が、いくつかのチューニング変数を失います。
“
”
引用元： http://docs.python.jp/3.3/library/re.html

しかも、両者は似ているようで微妙に違う ;(
これは困る
## re.compile().xxxx() 系
re.compile(pat, flags).match(string, pos, endpos)
re.compile(pat, flags).sub(repl, string, count)
## re.xxxx() 系
re.match(pat, string, flags)
re.sub(pat, repl, string, count, flags)
re.sub() は、 Python2.6では正規表
現フラグが指定できなかった
追加スライド
開始位置と終了位置が、re.compile().match()
では指定できるが re.match() ではできない

ところで re.xxxx() のやっていることは、内部で
re.compile().xxxx() を呼び出しているだけ
def compile(pattern, flags=0):
return _compile(pattern, flags)
def match(pattern, string, flags=0):
.match(string)
def sub(pattern, repl, string, count=0, flags=0):
.sub(repl, string, count)

だったら、全部 re.compile().xxxx() を使うように
すれば、re.xxxx() をなくして一本化できるよね？
re.compile()へのショートカット
rx = re._compile
## マッチング
m = re.match(r"(d+)", "123abc") # before
m = rx(r"(d+)").match("123abc") # after
## 文字列置換
re.sub(r".gif$", ".png", filename) # before
rx(r".gif$").sub(".png", filename) # after

一本化できれば、「似てるけど微妙に違う2系統」
が共存しなくてすむ
## re.compile().xxxx() 系
re.compile(pat, flags).match(string, pos, endpos)
re.compile(pat, flags).sub(repl, string, count)
等価 (当然)
## rx().xxxx() 系
rx = re._compile
rx(pat, flags).match(string, pos, endpos)
rx(pat, flags).sub(repl, string, count)
追加スライド

また1つの関数に5～6個も引数があるくらいなら、
2～3個の関数2つに分けたほうがわかりやすい
引数が5個！
## before
re.sub(pattern, repl, string, count=0, flags=0)
## after
rx(pattern, flags=0).sub(repl, string, count=0)
引数2個と引数3個

re.compile() は正規表現を必ずキャッシュする、
けどキャッシュする必要がないときもある
class HTMLHelper(object):
_ESCAPE = re.compile(r"[&<>"']")
クラス変数に保持しているので、ライブ
ラリ側でキャッシュする必要はない
（けど強制的にキャッシュされるので、
キャッシュが必要以上に肥大化する）

特に、たくさんの正規表現がデータとして与えられ
ると、キャッシュが無駄に肥大化してしまう
urlpatterns = patterns('',
url(r'^posts/$', "..."),
url(r'^posts/new$', "..."),
url(r'^posts/(?P<id>d+)$', "..."),
url(r'^posts/(?P<id>d+)/comments$', "..."),
url(r'^posts/(?P<id>d+)/edit$', "..."),
...
)
コンパイルするとすべて強制的にキャッシュされる
→ キャッシュする必要のないデータによって
　　キャッシュが肥大化する

Pythonの正規表現ライブラリは、キャッシュが肥
えすぎるとすべてパージしてしまう！
_cache = {}
_MAXCACHE = 512
キャッシュが肥大化する
→ キャッシュがパージされる
→ 性能低下 ;(
def _compile(pattern, flags):
...(snip)...
p = sre_compile.compile(pattern, flags)
if not bypass_cache:
if len(_cache) >= _MAXCACHE:
_cache.clear()
_cache[type(pattern), pattern, flags] = p
return p

キャッシュせずにコンパイルする機能が、公式に用
意されるとうれしい
class HTMLHelper(object):
_ESCAPE = re.sre_compile.compile(r"[&<>"']")
これならキャッシュしないので、
キャッシュの無駄な肥大化を防げる
（しかしunofficialなので使用には注意すること）

複数の正規表現にマッチさせるとき、こう書きたい
## ほんとはこう書きたい
if m = re.match(pat1, text):
x, y = m.groups()
elif m = re.match(pat2, text):
y, z = m.groups()
elif m = re.match(pat3, text):
z, x = m.groups()
文法エラー：
Pythonでは代入文は式ではないので、
if文の条件式には書けない

でもPythonではこう書くしかない
m = re.match(pat1, text)
if m:
x, y = m.groups()
else:
if m:
y, z = m.groups()
else:
if m:
z, x = m.groups()
if文のネストが深くなる

関数+return や、while文+break という手も
あるが、あまり嬉しくはない
while 1:
if m:
x, y = m.groups()
break
if m:
y, z = m.groups()
break
if m:
z, x = m.groups()
break
break
if文のネストは減ったけど、
トリッキーで間違えやすい

そこで、こういう機能はどうでしょう？
マッチングの対象文字列とマッチング結果を
保持するようなオブジェクトを用意すれば、
m = re.matching(text)
if m.match(pat1):
x, y = m.groups()
elif m.match(pat2):
y, z = m.groups()
elif m.match(pat3):
z, x = m.groups()
連続したマッチングが
素直に書けるはず

実装はこちら
class matching(object):
def __init__(self, string):
self.string = string
self.matched = None
http://bit.ly/matching_py
def match(self, pattern, flags=0):
self.matched = re.compile(pattern, flags)
.match(self.string)
return self.matched
def groups(self, *args):
return self.matched.groups(*args)

Questions?

おまけ: benry.rexp
https://pypi.python.org/pypi/benry
from benry.rexp import rx
## re.compile() へのショートカット
m = rx(r'pat', rx.I).match(string, start, end)
## キャッシュせずにコンパイル
rexp = rx.compile(r'pat', rx.I)
## 連続したマッチング
m = rx.matching(string)
if m.match(r'^(dddd)-(dd)-(dd)$'):
Y, M, D = m.groups()
else m.match(r'(dd)/(dd)/(dddd)$'):
M, D, Y = m.groups()

おしまい

正規表現リテラルは本当に必要なのか？

More Related Content

正規表現リテラルは本当に必要なのか？