_ Disgruntled Debian developers delay Etch

Debianの次期バージョンが遅れてますよというお話。 長年生温かい目で眺めてきた人間としては、ああやっぱりそうなるのね、 と言うしかないのだけれど、 しょーもない政治闘争で遅延が発生するというのは何ともはや。 Debianは昔からpolitical partyを連想させるプロジェクトだが、 もうちょっと技術的課題に集中できないのかねえ。 GNUにもそういう趣はあるけれど、 それが理由でリリースが遅れたという話は聞いたことがない。

_ Guido van Rossum on the Python 3000 process

要するに、 メタな話を延々繰り広げる奴が多くて、 もっと手を動かしてくれきゃ困るんだよ、 と嘆いておられるようで。 その気持ちは痛いほど分かるぞぉ。 メタな話になると、やたらぞろぞろ論客が発生するくせに、 具体的な話になると、途端に沈黙が訪れるというのは私もたくさん経験している。 邪魔になるようなら、非生産的な議論はすぱっと捨てるしかない訳で。

それはともかく、 PEP 3000 を眺めてみたのだが、 変更には大体同意する一方で、 大変そうだなあと感じる。 Python 3.0を作る人が大変だってことじゃなくて、 Python使っている人の側のこと。

Pythonはめちゃくちゃ互換性を重んじて開発されてきている。 一体何年前のコードまでそのまま動作するのだろう。 非常に長いことは確実だ。 逆に、相当我慢しなくてはならなかったことだろう。 一切失敗しないというわけにはいかないし、 そういうのが長年に渡って蓄積されてしまっている。 Python 3.0のメジャー・バージョン変更で、 そういうのを一気にかなぐり捨てたい気持ちはよく理解できるし、 いつかはやらないと仕方がないことだ。

とは言っても、大変になるなという認識は変えようがない。 例えば、unicodeはなくなる、というか、unicodeがstrになる。 これは正しい。 そもそも何でPythonにはunicodeとstrが別々にあるのか、 初心者には理解に苦しむところだろう。 方針としては正しい。 完全に同意する。 しかし、それに対応するのに発生する変更箇所がどれぐらいあるか考え始めると、 次第に気が滅入ってくる。

xrangeもなくなる。 正しい。 すごく正しい。 しかし2.xで性能を稼ごうとすると、xrangeを使わざるを得ない。 そうなると、両方で満足して動くコードを書くのは異常に大変だということだ。 安易に、

xrange = range

とかしてしまいたくなりそうだ。

callableもなくなるらしい。 確かになくてもいいと言えばいい。 でもcallableはいろんな場面で便利すぎる。 いちいち「try: ... except: ...」を書きたくなくことだってある。 なくなったら、結局自前で書くだけのような気がする。 っつーか、これがなくていいなら、hasattrも消えるべきだと思うのだが？

他にもたくさん変更はあるけれど、 3.xが現実に使われ始めるまで、まだ二年ぐらいはかかりそうな気がするので、 とりあえず今は気にしないことにしよう。