2009年07月24日

外部から停止可能なXMLRPCサーバ(Python2.X用)


taken by saschaaa (under CC)

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

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

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

続きを読む

posted by @shibukawa at 20:07 | Comment(64) | TrackBack(0) | Python はてなブックマーク - 外部から停止可能なXMLRPCサーバ(Python2.X用)

2009年05月28日

Pythonクックブック2nd 6.10をPython3.0に移植してみた

メソッドを保持する必要があったので、手元の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の違いもまとめておきます。

続きを読む
posted by @shibukawa at 22:08 | Comment(204) | TrackBack(0) | Python はてなブックマーク - Pythonクックブック2nd 6.10をPython3.0に移植してみた

2009年04月24日

The History of Pythonの日本語訳始めました。

The History of Python.jp

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

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

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

posted by @shibukawa at 08:35 | Comment(12) | TrackBack(2) | Python はてなブックマーク - The History of Pythonの日本語訳始めました。

2009年04月16日

with構文を試すためにテスティングフレームワークを作ってみた

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()
続きを読む
posted by @shibukawa at 21:36 | Comment(12) | TrackBack(0) | Python はてなブックマーク - with構文を試すためにテスティングフレームワークを作ってみた

2009年04月15日

In the Cloud or Not?の翻訳

最近英語に触れるきっかけが減っているので、バシバシ翻訳しています。これが終わったのでちょっと一段落して(まだ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はやりたいことが自由にできるコンクリートがむき出しの部屋を貸し出すのに近い。どちらにも市場はある。

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

posted by @shibukawa at 20:44 | Comment(11) | TrackBack(0) | Python はてなブックマーク - In the Cloud or Not?の翻訳

2009年04月14日

Scala?翻訳

またまた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)と呼ばれる)であるが、これは波カッコや丸カッコを同じセマンティクスで使用することができる。しかし、セミコロンの推測は、波カッコと丸カッコで異なるのである。えぇっ!:-)

posted by @shibukawa at 00:07 | Comment(37) | TrackBack(0) | Python はてなブックマーク - Scala?翻訳

2009年01月29日

「Djangoミドルウェア作ってみた」

「アナログ」

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

続きを読む
posted by @shibukawa at 00:00 | Comment(160) | TrackBack(0) | Python はてなブックマーク - 「Djangoミドルウェア作ってみた」

2008年10月24日

「[翻訳]Pythonを使って2MBのメモリで100万の数値をソートする」

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


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

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

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

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

続きを読む
posted by @shibukawa at 00:00 | Comment(203) | TrackBack(0) | Python はてなブックマーク - 「[翻訳]Pythonを使って2MBのメモリで100万の数値をソートする」

2008年06月17日

「ジャンケンプログラムのソースコード」

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

janken-20080617.zip(8KB)

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

続きを読む
posted by @shibukawa at 00:00 | Comment(127) | TrackBack(0) | Python はてなブックマーク - 「ジャンケンプログラムのソースコード」

「ジャンケンWebサービス」

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

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

以下簡単な使い方。

続きを読む
posted by @shibukawa at 00:00 | Comment(144) | TrackBack(0) | Python はてなブックマーク - 「ジャンケンWebサービス」

2008年06月02日

「web.pyトライ中」

簡単だね〜。結構楽しい。せっかくシンプルなので、もっとシンプルになるようにDBを使わずpickleを使ってみる。pickleで文字列化した辞書を書き込んだファイルをDB代わりにして、cookbookに載っていたファイルのロックで保護。うまくライブラリ化すれば、少人数でのミニwebサービスを気軽に作るための部品にできそうです。

ところで、web.pyでHTML出力をすると、最後の何文字かが欠けるんだけどどなたか理由わかりません?文字数のカウントしてないけど、文字数とバイト数の差かな?content lengthの所の値がおかしい可能性が高そうです。
posted by @shibukawa at 00:00 | Comment(175) | TrackBack(0) | Python はてなブックマーク - 「web.pyトライ中」

2008年05月17日

「オンラインじゃんけん」

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

続きを読む
posted by @shibukawa at 00:00 | Comment(174) | TrackBack(0) | Python はてなブックマーク - 「オンラインじゃんけん」

2008年03月18日

「Python 3000 and Youの翻訳」

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


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

続きを読む
posted by @shibukawa at 00:00 | Comment(14) | TrackBack(0) | Python はてなブックマーク - 「Python 3000 and Youの翻訳」

2008年03月14日

「[PyDevCamp2008]自分のセッションの振り返り」

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

続きを読む
posted by @shibukawa at 00:00 | Comment(169) | TrackBack(0) | Python はてなブックマーク - 「[PyDevCamp2008]自分のセッションの振り返り」

2008年03月12日

「[PyDevCamp2008]学んだことの振り返り」

[PyDevCamp2008]看板

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

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

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

[PyDevCamp2008]GAINER続きを読む
posted by @shibukawa at 00:00 | Comment(206) | TrackBack(0) | Python はてなブックマーク - 「[PyDevCamp2008]学んだことの振り返り」

2008年02月09日

「Python Developer Camp2008」

3月の始めに,長野県松本市合宿を開催いたします。Pythonに興味のある方を対象にした合宿です。Python漬けの三日間で,Pythonへの愛と確信を深めましょう:-)。参加希望の方は,Google Groupsに設置のメーリングリストに加入してください。みなさまのご参加をお待ちしております。

■ 開催概要

* 名称 Python Developers Camp 2008 冬
* 日時 2008年3月7日(金)〜9日(日)
二泊三日(土曜泊のみの方の参加も歓迎します)
* 場所 松本ホテル花月
* 対象 Pythonに興味のある方
* 費用 交通費,宿泊費を含んだ実費
宿泊費は交渉中ですが、1泊あたり1万円+会議室代1000円程度を予定
* 主催 Python Developers Camp 2008 冬実行委員会
* 締切 現地参加の締め切りは2月16日です。




続きを読む
posted by @shibukawa at 00:00 | Comment(123) | TrackBack(0) | Python はてなブックマーク - 「Python Developer Camp2008」

「PySpec-0.53の進捗」

http://www.codeplex.com/pyspec/

開発はちょっぴり進行中。

・should_includeの逆、should_be_inを実装。対象のデータが、配列なりなんなりに含まれているかどうかの判定メソッド。予定にはなかったけど思いつきで。

・dprint()を実装。呼び方はPython3000のprint関数に準拠。呼び出したファイル名、行番号、変数名が表示されるおまけ付き。究極のprintfデバッグをあなたに。

・レガシーコードのための機能は核となる部分を実装。データを記録、呼び出しをする仕組みができました。後は、フレームワークに組み込めばベースは完了。後は、should_not_be_changed()メソッドのように、簡単にテストが書けるような仕組みを整えればOK。

まったく手つかずはデバッグ用のスタックトレース表示メソッドぐらいかな。これもベースとなる部分は既にPySpec自身が利用しているので、それをテストコードプログラマー向けに形を整えればおしまいかな。今回はきちんと実践的なチュートリアルを書く予定。docutilsの拡張を、レガシーサポート機能を使って行う、というストーリー。

0.54は何を実装しようかなぁ。doctestでも取り込んでみるかな?中長期の目標としてはWSGI対応してWebのテストに対応することかな。ユーザの入力と反応とか、もうちょっと上の層のテストが簡単にかけるようにしたいな。

そういえば日本語のマニュアルをまだ書いてなかったな。
posted by @shibukawa at 00:00 | Comment(149) | TrackBack(0) | Python はてなブックマーク - 「PySpec-0.53の進捗」

2008年02月04日

「PySpec-0.52リリース完了」

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

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

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

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

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

posted by @shibukawa at 00:00 | Comment(17) | TrackBack(0) | Python はてなブックマーク - 「PySpec-0.52リリース完了」

2008年01月31日

「PySpec-0.52実装完了」

http://www.codeplex.com/pyspec

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

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

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

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

posted by @shibukawa at 00:00 | Comment(151) | TrackBack(0) | Python はてなブックマーク - 「PySpec-0.52実装完了」

2008年01月26日

「PySpec0.52の予定機能」

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とかも作りたいです。情報収集は完了。後は作るだけ。

posted by @shibukawa at 00:00 | Comment(61) | TrackBack(0) | Python はてなブックマーク - 「PySpec0.52の予定機能」
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2016年12月 >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ