西尾泰和のブログ @ Cybozu Labs

>>> import md5
>>> md5.md5("Python")

>>> _.hexdigest()
'a7f5f35426b927411fc9231b56382173'

Pythonはまぁ蛇という意味で一般名詞としても使われるので「YRAV」で試してみたところこんなサイトが…：The MD5 Collision Database: Starting with YAR

「Python」の代わりに「Pyth0n」にしてみると何もヒットしませんでした。結局「十分長く」「辞書的単語でない」単語を使わなければ簡単に逆変換できてしまうと言うことですね。

対処方法：

• 別のIPアドレスからログインする
• /var/db/ssh-bruteforceに記録されている自分のIPアドレスを削る(もしここにデータファイルがなければ、ps -xでbruteforcebrockerの場所を調べ、中を見て設定ファイルの位置を調べ、その設定ファイルを見ると書いてある)
• /etc/rc.d/pf restart でパケットフィルタを再起動する

あんまり変なことをしないように気をつけないと…(^^;

ので、

Pythonで書かれているKEMURI のインタプリタを<script type="text/python4js">で囲ってHTMLソースに書いておくと、それがJavaScriptに変換されて実行される、というデモを作ってみました。

Python4JS and KEMURI Interperer on it

ラボでは他にも JSRuby - Javascript による Ruby(っぽい)実装 (nakatani @ cybozu labs) などが公開されていますが、僕のこのデモは深夜ノリで作ったため、Python2.5の全機能をサポートしているわけではありません。今後改良していく予定もありません。ごめんなさいごめんなさい。ソースコードを見て石を投げないで！

下のようなモデルの定義から自動的に生成されます。

class Comment(models.Model):
    topic = models.ForeignKey("Topic", null=True, blank=True)
    parent = models.ForeignKey("self", null=True, blank=True)
    create_date = models.DateTimeField()
    author = models.ForeignKey(User, null=True)
    body = models.TextField(blank=True)

すごく楽ちんだったのですが、どう書くorgがにぎわってコメント数が増えてくるに従って どんどん重たくなってきました。

理由はとても簡単で、この自動生成されたリストの部分で、 数千件あるすべてのコメントをデータベースから取ってきて文字列にする処理が行われるからです。

↑数千件がリストの中に…

このせいでページを開くだけで30秒程度かかっていました。 この問題はどうすれば解決できるか。 実はすごく簡単で、フィールドの定義にrw_id_admin=Trueをつけるだけでした。

-   parent = models.ForeignKey('self', null=True, blank=True)
+   parent = models.ForeignKey('self', null=True, blank=True, raw_id_admin=True)

虫眼鏡アイコンを選ぶとアイテムの一覧が別ウィンドウで開きます。

テーブルが大きくなってくるとリスト表示では探すのも面倒になるので、 大きくなりそうなテーブルへForeignKeyを張っているなら今のうちにraw_id_adminをつけておくのも手かもしれません。

どう書くorgについてオフィシャルに言及するのは初めてなのですが、 アルファ版の時点ではてなブックマークのホットエントリーになったり、 オレンジニュースや やじうまWatchで言及していただいたりしたので すでにご存じの方もいらっしゃるかもしれません。 そこでこの記事では今まで語ってこなかった「どうして『どう書くorg』を作ろうと考えたのか」について解説したいと思います。

そもそものきっかけはマルチリンガルなシソーラス検索 - rubyco（るびこ）の日記でした。 言語Xを使っている人が新たに言語Yを使うときになにが障害になるか、というと、 やはり「言語Xでならどうやるか0.1秒で思いつくような簡単な内容を、 言語Yではドキュメントをひっかきまわして探さないといけない」というフラストレーションなわけです。 そのフラストレーションを避ける気持ちが、プログラマを「自分が一番慣れている言語」という檻に閉じこめるのです。 プログラミング言語間の対訳があれば、殻を破ってマルチリンガルの大空に羽ばたくことができるのに。

さて、この対訳マルチリンガル・クックブックを作る上で、 まずは「Wikipedia的なアプローチで言語間の対訳データが集められないか」 と考えPukiWikiで集積サイトを作りました。 しかし「これは絶対に盛り上がらない」と判断して公開しませんでした。 単なるWikiではコードを書いてもらうインセンティブに欠けると思いました。

その後、どういう流れがあったのかは正確には覚えていません。しかし、いつしか キミならどう書く 2.0 - ROUND 1 - Lightweight Language Ring のようなアプローチをもったいないと感じるようになりました。 お題に対してコードを書いている人のほとんどは、そのコードの再利用を禁止したいとは思っていないはずです。 なのに、許可を明示的に取らないせいで実質的に再利用できずに散逸させてしまっています。 せっかく無償でいろいろな言語のコードを書いてもらうことができているのに。これはとてももったいないことです。

このようにして「どう書くorg」の三本柱「マルチリンガル志向」「お題にチャレンジ」「再利用可能なライセンス」ができました。 みなさんのおかげで、7月頭にどう書くorgを公開してから今までの4ヶ月弱で、2796件のコードが投稿されています。 1日平均20件以上という計算になります。

今後の課題は、こうやって集まったコードをどう加工するかだと思います。 指定したコード中から特定の文字列を検索して、同じお題の別の言語のコードを表示する機能 を3ヶ月も前に実装したのですが、これは現状の「お題と解答」というシステムではコードの粒度が大きすぎてなかなか望み通りのものが得られません。 ソースコードを静的に解析することで使われているモジュールを推定する機能(どう書く？org Python 使用モジュール一覧) がついたので、次は「同じお題で使われることの多いモジュールは似た機能のモジュール」というような推定でしょうか。 それとも、お題にするには粒度が小さすぎるような内容を 文字列中のアルファベットを大文字にする どう書く？org のような公開トピックとしてどんどん作ることで粒度の小さいコードを増やすのがいいのでしょうか？ まだまだ先が見えません。

しかし、たとえどう書くorgプロジェクトが道半ばで頓挫しても、 集まった「自由に再利用できる」コードは他のプロジェクトの肥やしになるはずです。 進めるところまで進んでみるのが正解かな、と思っています。

長々と昔話や妄想を書きつづってきましたが、まとめたいと思います。 どう書くorgは今まで「出されたお題をいかに解くか競い合う、プログラマのためのコロシアム」と名乗っていました。しかし「プログラマのためのコロシアム」なのは手段であって目的ではありません。どう書くorgの目的は「マルチリンガル・クックブック」を自然発生させることなのです。

そこで「一度deprecated(非推奨)にする」という方法を考えました。

まず下のようにfooという関数と、それを読んでいるcallerという関数を作りました。今からこのfooをbarという名前に変更したいと思います。 しかし、実際にはcallerは大量のソースの中に散らばっているものとします。

>>> def foo():
	return 1

>>> def caller():
	return foo()

>>> bar = foo
>>> def foo():
	import inspect
	print "'foo' is deprecated: called from", inspect.stack()[1][3]
	return bar()

>>> caller()
'foo' is deprecated: called from caller
1

>>> def deprecated(f):
	def deprecated_func(*args, **kw):
		import inspect
		print "'%s' is deprecated:" % f.func_name,
		print "line %s in '%s'" % tuple(inspect.stack()[1][2:4])
		return f(*args, **kw)
	return deprecated_func

>>> def nibai(x):
	return x * 2

>>> def foo():
	print nibai(10)
	print nibai(20)

	
>>> foo()
20
40
>>> nibai = deprecated(nibai)
>>> foo()
'nibai' is deprecated: line 2 in 'foo'
20
'nibai' is deprecated: line 3 in 'foo'
40

>>> p = dict(x=1, y=2)
>>> p
{'y': 2, 'x': 1}
>>> p['x']
1

>>> p = modulize(p)
>>> p.x
1

>>> def modulize(dictionary):
	import imp
	m = imp.new_module("")
	m.__dict__.update(dictionary)
	return m

>>> p = dict(x=1, y=2)
>>> p2 = modulize(p)
>>> p2.x = 100
>>> p
{'y': 2, 'x': 1}

>>> p2.__dict__
{'y': 2, '__name__': '', '__doc__': None, 'x': 100}

>>> class MyDict(dict):
	__getattr__ = dict.__getitem__
	__setattr__ = dict.__setitem__
	__delattr__ = dict.__delitem__

	
>>> MyDict()
{}
>>> d = _
>>> d.x = 1
>>> d
{'x': 1}
>>> d.x
1
>>> del d.x
>>> d
{}

前回は 「関数を与えると、その関数を呼び出さずに、その関数が起こしそうなNameErrorを警告する」 というものでしたが、今回はモジュールとネストしたコードオブジェクトをサポートしました。 ファイル名を指定して、そのファイルが起こしそうなNameErrorを警告させることが可能です。

たとえば下のような内容のファイル(tests/test_target.py)があった場合に

def some_func():
    pass

def foo():
    print some_finc()

C:\Python25\Lib\site-packages>find_name_error.py coda\tests\test_target.py
line 5: some_finc

使い方：まずScriptsフォルダに入っているfind_name_error.pyを C:\Python25\Scriptsなどのパスの通っている場所に移動してください。 このとき、名前は適当に変更しても構いません。

適当なフォルダに移動して-hというオプションで起動してヘルプが出ればOKです。

C:\>find_name_error.py -h
Usage: find_name_error.py [options]

Options:
  -h, --help            show this help message and exit
  -r DIR, --recursive=DIR
                        find *.py under the directory
  -w, --watch           watching target continuously(not implemented yet)

ソースコードは共有リポジトリ CodeRepos::Share で公開中です。 Subversionがインストール済みであれば、たとえば 下のようにしてPythonのsite-packages内でチェックアウトするだけでOKです。

C:\Python25\Lib\site-packages>svn co http://svn.coderepos.org/share/lang/python/coda/trunk/coda

Subversionを入れたくない人のために一応ZIPで圧縮したバージョンも置いておきます。

Coda rev 228

既知の問題点はこちら： /lang/python/coda/trunk/PROBLEMS_JA.txt - CodeRepos::Share - Trac

鮎川さんからご指摘のあったユニコード文字列のstrでエラーになる件は、 使っているエンコーディングによってエラーになったりならなかったりするので、 近いうちにユーザがエンコーディングを指定できるようにします。

そこで「先日公開したCodeHackモジュールを使えば簡単にできるよ」と言いながら作ったのが今回紹介するモジュールです。 CodeHack 0.05に同梱しました。 CodeHack 0.06に同梱しました。

使い方は簡単です。 たとえば下のような関数fooを定義したとします。

def foo(left, top, right, bottom):
    "function for test"
    width = right - left
    hieght = top - botom
    print height, width

>>> from codehack.var_warning import checkfunc
>>> checkfunc(foo)
variable 'botom' is global
variable 'height' is global
variable 'hieght' is not used
variable 'bottom' is not used

ただ、そのままですと'range'や'set'なども警告されたり、 自分で定義したグローバル関数を使うとそれも警告されたり、 とうっとうしいことになるので、 警告しない名前のリストをsurpressという引数で指定できるようにしてあります。 デフォルトでは組み込みの名前(rangeとか)がsurpressに入っています。

def checkfunc(func,
          print_globals = True,
          print_not_used = True,
          print_func_name = False,
          surpress = _default_surpress):

CodeHackモジュールを使っている部分は、実はたいしたことはしていません。 下のようにLOAD_FAST(ローカル変数のロード)という オペコードの引数(変数名になっている)を集めているだけです。 codehack.util.analyzeはオペコード間の依存関係(どのオペコードが積んだ値をどのオペコードが消費するか)のトレースをするのですが、それも必要ないのでわざわざ外しています。

    import util
    opcodes = util.analyze(func, do_trace=False)

    loaded_vars = set(op.argstr
                for op in opcodes
                if op.opname == "LOAD_FAST")

>>> from codehack.var_warning import checkfunc, checkall
>>> import urllib
>>> checkfunc(urllib.urlopen)
variable 'FancyURLopener' is global
variable '_urlopener' is global
>>> checkall(urllib.__dict__)
* function splitnport
* function getproxies
* function retrieve
variable 'msg' is not used
variable 'garbage' is not used
(snip)

(注1) 実際はもちろんグローバルの名前空間にいきなり行くわけではなくて、 スコープがネストしている場合には1枚外のスコープへ行きます。 globalと呼んでいるのは単にバイトコードがLOAD_GLOBALだからだったりします。 いい名称があれば変えたほうがいいかもしれません。 また、関数がネストしている場合は内側の関数で使われる変数を 「使われる」と判断することができずに警告を出してしまいます。 これはdisしてみるとわかるのですが、内側の関数はコードオブジェクトとして 定数テーブルに埋め込まれているため、 外側の関数のバイトコードを見ただけでは内側で何を使うかがわからない ことが原因です。定数テーブルにコードオブジェクトがあるかどうかをチェックして 再帰的にたどるようにすればいいだろうと思いますが…それは今後の反響次第と言うことで。

「Pythonコード添削道場」はこのワークショップのセッションの一つで、私、西尾 泰和と増田 泰さん、柴田 淳さんの3人で投稿されたコードを添削するという企画です。

この企画はみなさんにコードを投稿して頂かないと始まりません。 コードの内容は自由なので、ぜひご投稿ください。

また「投稿してといわれても、ちょうどいいコードがないなぁ」 という人のために、お題が7つ用意してあります。 お題に挑戦してみて結果のコードを投稿するのもよいでしょう。

コードの投稿の際に名前を書く必要はありません。 完全に匿名でも、自分にしかわからないような ハンドルネームでもOKです。 その方が添削する我々も、容赦なく添削ができます。

自分のコードが容赦なく添削される機会は、 そうそうあるもんじゃないですよ！ ぜひこのチャンスをものにして 理解を深めるきっかけにしてください。

お題は以下の7問です。

• お題１：ファイルの同期
• お題２：単語数カウント
• お題３：シングルトン
• お題４：入れ子リストの中身を順に表示
• お題５：行列の回転
• お題６：名簿の並び替え
• お題７：整数とビット列の相互変換