渋日記@shibu.jp

taken by saschaaa (under CC)

XML RPCで最近良く遊んでいます。ぱっとサーバを立ち上げて、インタラクティブモードでクライアントを起動して、すぐにメソッドを呼び出したり、すごく便利です。dRubyみたいに、クライアントとサーバの区別なく使えて、コールバックもできて、オブジェクトも渡したりできるような仕組みと比べると低レベルですが、ちょっとした通信では結構便利です。

ですが、標準のSimpleXMLRPCServerを使って分かったのは、Djangoのテストサーバの偉いところです。Ctrl+Cを押すとその場でぱっと止まってくれます。でも、自分でSimpleHTTPServer, SimpleXMLRPCServerなんかを起動すると、止まってくれません。気軽にインタラクティブモードで起動したり閉じたりするのには不便です。Djangoは別にプロセスをあげてそこで起動しているため、メインプロセス側のKeyboardInterruptをうまく捕まえて処理できているようです。では、通常のサーバではそこまでやらなければならないのか、というと、別の方法があります。下記のサイトを参考にコードを書いてみました。

• Python で TCPServer/socket.accept を使う場合の注意

それでは、作った物を公開します。

続きを読む

メソッドを保持する必要があったので、手元のPython クックブック 第2版を紐解いて「ガベージコレクションを邪魔することなく結合メソッドへのリファレンスを保持」を打ち込んでみたのですが、Python3.0の変更点がいくつかヒットしていてそのままじゃ動きませんでした。元のコードはこちらのコメント欄の一番下のコードです。

使われ方としては以下のサンプルの通り。メソッドをそのまま保持してしまうと、インスタンスメソッドを保持しているオブジェクトまで削除しないと生きたままになってしまうので、weakrefを使うといいよ、という感じのティップスです。

>>> class C:
...   def f(self):
...     print "Hello"
...   def __del__(self):
...     print "C dying"
>>> c = C()
>>> cf = _weekmethod_ref(c.f)
>>> cf()() # この段階ではインスタンスcが生きているので使える
Hello
>>> del c # cを殺してみる
C dying
>>> print cf()
None

コードだけ書くのもいいけど、せっかくなので今回分かったPython2.Xと3.Xの違いもまとめておきます。

ちょっと前からPython作者のGuidoも参加しているThe History of Pythonというブログが気になっていたので、翻訳許可をもらって翻訳作業を開始し始めました。さっそく本家の方で紹介されてしまってプレッシャーも出てきたけど、ガンガン訳して本家の公開ペースに追いつこうと思います。幸い、まだそんなに数も出てないしね。

C++の設計と進化という本を読んだ時に、歴史を知ることから学べることって多いよね、ということをすごく実感し、C++の欠点も含めて好きになったので、そういう体験をPythonを使っている人にも、使っていない人にも提供できたらいいな、と思っています。Have fun!!

http://python-history-jp.blogspot.com/

Pythonの2.6から入ったwith構文。どうやって使うのかな？とコードをいじいじしていたらテスティングフレームワークができました。withはRubyのブロックと比べてみると・・・

• その段階に来たときに即実行される
• ブロックを扱うというか、前後に処理を挟む感じ
• RubyのFileやLockのイテレータのようなものは実現可能
• RubyのThreadのイテレータは実現不可能っぽい

作ってみたテスティングフレームワークの使用サンプルは以下のような感じです。無理矢理フル機能を見せるデモになってます。本体のコードは続きを見る、の先に貼り付けました。実装した機能はこんな感じです。

• with simple_test("sum"):という感じでテストを定義
• @setup, @teardownで、準備、片づけのメソッドを定義できる
• test_manager.show_result()を最後に実行すると結果を表示する。
• テストケース内のprint文の出力は、結果と一緒に、テストごとに表示される。ただしエラーメソッドのみ。

@setup
def setup_method(context):
   print "test_start", context.test_name


@teardown
def teardown_method(context, is_success):
   print "test_end"


with simple_test("sum"):
   a = 10
   b = 20
   print "a =", a
   print "b =", b
   assert 30 == a + b


with simple_test("error"):
   a = 15
   b = 20
   print "a =", a
   print "b =", b
   assert 30 == a + b

test_manager.show_result()

最近英語に触れるきっかけが減っているので、バシバシ翻訳しています。これが終わったのでちょっと一段落して(まだGuidoのブログで訳したいのもいくつかありますが)、GTD方面の翻訳もそろそろやります。

In the Cloud or Not?

原文：http://neopythonic.blogspot.com/2008/12/in-cloud-or-not.html

クラウドをとても好きな人がいる。ここでいうクラウドというのは、Google AppEngineやAmazon EC2, MicrosoftのAzureのようなクラウドコンピューティングのことである。一方、クラウドが嫌いな人もいる。これを嫌うような人は、ロックインや、APIの独占なども嫌う傾向がある。(両方の姿勢の例を提示したいと考えているが、ちょうど今は時間がないので勘弁してほしい。情報を集めるのは簡単だから:-)

新しい分野かどうかはさておき、これらの意見の相違が、持ち家に対する意見の相違と同じではないか、と心配になる。「借りる」ということを嫌う家族がいたり、家主との係争を引き合いに出したり、近所の人がうるさかったり、終わることのないメンテナンス(屋根、フェンス、暖炉、バスルーム、キッチンなどきりがない)があったり。私自身は中間であるが、過去には良い家主に会うことが出来たり、最近の自分自身の家のメンテナンスの努力・コストがいやになりつつも、独立していることを楽しんでもいる。

明らかに、クラウドコンピューティングはこの借家に近い。伝統的なデーターセンターの所有権が家の所有権となっているのである(建造するコストを無視して、所有することなしに利益を上げることを考えてみてください:-) アナロジーを使い、大家ができるビジネスの方法として、クラウドサービスのスタイルの違いの比較を行う人もいるだろう。例えば、Google App Engineはカーペットも家具もサービスの一部として含まれるが、食事の配達はオプションである。Amazon EC2はやりたいことが自由にできるコンクリートがむき出しの部屋を貸し出すのに近い。どちらにも市場はある。

このクラウドの課題に関して、好き/嫌いという論争は止むことがないと考えるべきである。クラウドを嫌っている人を好きになるようにと説得することはない。しかし、自分のサーバを所有したくないと考えている家主に対するビジネスはたくさんあるのである。我々はクラウド嫌いの人と一緒に仕事してがっかりするのはやめて、そのような人たちに喜んでもらうことをしたほうが良いだろう。

またまたGuidoのブログの翻訳です。GuidoがScalaを語ってる！と思ったら、なんか色々不満なご様子。Scala用語はイマイチ分からぬことも手伝って、相変わらず適当翻訳ですがどうぞ。

Scala?

原文：http://neopythonic.blogspot.com/2008/11/scala.html

私は、Scala eBookの無料コピーをMartin Odersky氏, Lex Spoon氏, Bill Venners氏の三名からいただいた。私は、CalTrain(訳注：アメリカのカリフォルニア州を走る通勤電車)で通勤中に読もうと挑戦してみたが、ざっと内容をつかむことしかできなかった。700ページ以上ある大作の本である。私はもちろん、この書籍のターゲットの読者ではない。この本のターゲットは二つあり、一方はより良い言語に挑戦しようとするJavaプログラマーへの誘惑、もう一方はScalaを使うとどのようなことが起きるのか、という紹介である。その二つの間を行き来している感じである。私は最終的にはScalaのウェブサイト(チュートリアルや概要、言語リファレンスなどをダウンロードした)を訪れることになった。

これを言わなければならないのは残念ですが、私はとてもがっかりしています(あ、言語にです。eBookのほうは、言語使用と同じぐらい大きいということを除けば、言うことは何もありません)。私が最初にScalaについて聞いたのは、昨年の5月のGoogle I/Oで、Steve Yegge氏との会話の中で触れられていたときのことである。SteveはScalaを「静的な型システムの逆襲」 (そのセクションのビデオを見つけるのが面倒なので、てきとーに言い換えています)。Steveは信じられないほどフクザツな型システムをからかい始めた。例えば、型システムには、型の消去、分散アノテーション(variance annotation) 、実存(existential)型、ポリモーフィックメソッド型など、難解なコンセプトがたくさん含まれているのである。もしより知りたければ、言語リファレンスのToCという項目を調べて見ると良い。

私はSteveに同意せざるを得ない。もしこれがコンパイル時の言語内の型セーフを維持するためのものであるならば、私はいつでも動的な型システムを選択するだろう。より良いやりかたがあるはずである。おそらくHaskell？Haskellは純粋な関数型言語で、関数型言語のI/Oの問題をうまい具合に解決した、動作の速い実装が存在する。Haskellのモナドは本当に深く、実装はかなり大変であるが、これを使うのは極めて簡単であるように思える。

私がScalaを見て、もっともがっかりした点が、簡単そうに見えるコードを書くことを可能にするような、無数のルールがあるということである。これらのルールはすべて、無数の例外のように見えた。これらの例外により、これらを知らないときにはシンプルなコードを書くのがとても難しくなる。例えば、Scala本では、for構文の中ではif修飾詞をいくつも使用できると説明されている。しかし、パーサに推測して欲しいという位置にセミコロンを挿入してやる必要がある。さらに不可思議なのは、丸カッコの代わりにもし波カッコ({})を使用したときに、セミコロンが省略できるのである。説明も無く、このようなことが堂々と現れるのである。私は、リファレンスマニュアルの内のほとんど関係がないように思えるルールを結び付けて説明を理解した。まずはforステートメント(技術的にはfor内包表記(comprehension)と呼ばれる)であるが、これは波カッコや丸カッコを同じセマンティクスで使用することができる。しかし、セミコロンの推測は、波カッコと丸カッコで異なるのである。えぇっ！:-)

Djangoのミドルウェアを作ってみました。すごく簡単でした。デバッグモードで実行していると、右上に「アナログ」と表示します。まぁ、あれです。ミドルウェアというのは、入出力をいじくったりすることができる拡張機能です。簡単な例だと、ケータイ向けにコンテンツを編集する、というのもミドルウェアを作ることで実現できます。Djangoだと、クラスを一つ作り、いくつかメソッドを定義してやるだけで簡単に作れます。

Pythonの著者のGuideのブログが引っ越しをしたようです。そこに載っていた記事を一本翻訳してみました。今マイブームはオペラ座の怪人で、楽譜を買ったり、小説を買ったりして読んでいるんですが、小説の日本語がやたら直訳で堅いんです。柔らかい翻訳に触れたくて、衝動的に翻訳してみた次第です。動機とPythonは何の関係もないですが。

誰かからジョーク交じりに、100万個の32ビットの数値を2メガバイトのメモリでソートできるか？と聞かれたことがある。私はこれに挑戦してみたが、この中でI/Oのバッファリングについていくつか学ぶことができた。

明らかにこの問題はジョークである。バイナリエンコーディングだと仮定してもデータだけで4メガバイトになってしまうのである！しかし、これを可能にする実装方法がある。32ビットの数値が100万個納められているファイルがあるとして、どのようにすればメモリの使用量を最小にしてソートをすることができるだろうか？これは一種のマージソートになるはずである。メモリ内でソートされた小さいチャンク(かたまり)を一時ファイルに保存し、その後この一時ファイルをマージして最終的な出力エリアに出力する。

これは私の考えた解決策である。手短に(1分で)説明しよう。

NOTE: すべてのサンプルはPython3.0を使用して書いた。主な違いはバイナリストリームにアクセスするのにfile.bufferを使用している箇所である。

ソースコードをアップロードしました。

設置したい人がいるか分からないけど、とりあえず置き方の説明です。

http://www.shibu.jp/janken/

できました。何人かで飲み会の計画を立てたけど、全員の予定の合う日がなくて誰かを切り捨てないといけない！という場面で使います。ジャンケンの手を入力するのは各人なので、責任はそれぞれ本人にあります。誰も恨みっこなしよ、ということで、思想的にはサイコロ様に近いところがあるんじゃないかと思います。

以下簡単な使い方。

飲み会の日程を決めようと思ったら、微妙に日程が合わなかったなんてことないですか？そんなときに使えるPythonスクリプトです。アルゴリズムが公開されている(というか周知)ので公平ですよね。以下のプログラムは超手抜きなので、3人中2人の勝ちを決めるプログラムになっています。勝ち、負けの人数を柔軟に変えるようにするのは難しくないと思うので、Python勉強中の方は挑戦してみてください。ついでにDjangoとかPylonsでWebサービスにしてもいいかも！？

Python作者のGuideのブログの記事を軽く翻訳してみました。単語を適当に抜かしたりしていますが、だいたいはそのままです。Guideらしいというか、Pythonらしいコメントですね。もちろん、この方針はPython以外にも使えます。

私がこの機会を利用して、ここを見ている方々に本当に伝えたいのは、Python3000にモジュールを移植するときにAPIを変更してはいけないということです。ここを見ている方は以下の話は聞いたことがあるでしょう。Python3.0はAPIが変更になり、後方互換性がなくなる、と。しかし、開発者の方々(特に他のユーザから使用されているライブラリの)はAPIを変更してはいけません。もし変更する予定があるならば、3.0に移植する前に行ってください。あるいは、3.0に変更なしで移植したあとに行って下さい。

今回はユニットテストの担当をさせてもらったわけですが、色々、うまく理解してもらえるように工夫をしてみました。結果的には時間が足りなかった、というのはあるけど、今回のセッションを発展させて、自分の定番にしていきたいと思います。今回が記念すべき第一回。KPT方式で箇条書きでまとめます。

Python Developer Camp 2008 winterに行ってきました。初日の行きの会話からして濃かったです。この行きの会話だけでもLTネタになりそうなぐらい。語りたいことはいっぱいあるのですが、まずは全体のアウトラインから。

僕の参加したセッションは主にPylons, Buildbot, モンティ・パイソン。まぁ、数は少ないけど、それなりに密度は高かったと思います。横目でじっと見ていたのはNodeBoxとGAINERです。マックは壊れたMac miniしかないからなぁ。GAINERは春休みの宿題にします。そして、主催者側でやっていたのは、ユニットテスト, LT, 初日の晩の飲み会です。二日酔いになったけどw

↓おいしいところを全部持って行ったGAINER

PySpec-0.52をリリースしました。

今回の目玉機能、というか、今までも入っていたけど、きちんとドキュメントに書いた機能がいくつかあります。

• reST形式でレポート出力機能
• CUIにもアドイン機構を実装(上記機能はこれを利用)
• 契約による設計(Design by Contract)のサポート
• textuiのモジュール名とかを変更
• ドキュメントをいくつか追加で書いた

コード自体の変更はあんまりないけど、ドキュメントの準備とかに時間かかるね。早いところ、reST2codeplex変換プログラムを作らないと。

次は、レガシーコードのテストのための機能拡張を考えています。

実装は完了したんですが、ドキュメントはまだです。今回はDesign By Contract機能をPySpecに統合したので、その周辺の説明かな。後はレポート出力機能。

ドキュメントに関しては、手つかずなところも多いです。以下の項目は今後やっていこうと思っていることです。

• reStructuredTextからcodeplexのwikiに変換するプログラム作成
• テストランナーの使い方、オプションの説明資料
• Design By Contract機能を使ってレガシーコードの拡張をするチュートリアル
• プラグインの作成の仕方
• PySpecの内部仕様に関するドキュメント

レガシーコード用のテスト用に、過去の結果と違っていたら例外を投げる、About(XX).should_not_be_changed()というのは実装しようと思います。新規開発だとあんまり使わないかも。

PySpecの次期バージョンに向けて手を加えています。次の項目を検討中。

• text**をcui**に改名
• CUISpecRunnerにプラグイン機構を実装(wxuiの流用だけど)
• CUISpecRunnerのプラグインとしてHTML結果出力を実装
• CUISpecRunnerのプラグインとしてreST結果出力を実装
• PySpecのコアの一部をpyspecモジュールからpyspec.embeddedに移動
• pyspec.embeddedにDbCなどアプリに組み込んでテストする機能一式をそろえる

機能的な目玉はテストレポート出力とDbCかな。2月の最初の週ぐらいまでには出したいね。

HTMLやreSTをどうやって生成するかだけど、自作のJSONtoXML関数(pyspec.utilに実装済み)を使うとカスタマイズ性が悪いので、同じMITライセンスのtempitaを組み込む予定。Pythonにはテンプレートエンジンがそれこそきら星のごとくたくさんあるのだけど、決め手はファイルサイズの小ささ。

あと、今手変換が面倒な、reST形式のドキュメントをcodeplexのwikiフォーマットに整形するwriterとかも作りたいです。情報収集は完了。後は作るだけ。