mockはこう使え - atsuoishimoto's diary
最近、Mockライブラリ http://www.voidspace.org.uk/python/mock/ を使ってみたのでメモ。 このライブラリは、その性質上、動的にメソッドや属性を作成するケースが多く、普通のPythonライブラリのようにイントロスペクションに頼って使い方を調べるのは難しい。本気で使うならまじめにドキュメントを読み込む必要がある。 関数の置き換え テスト中に呼び出される関数をMockで置き換える例。ここでは、関数 myapp.utils.func1() を置き換える。 from mock import Mock import myapp.utils # myapp.utils.func1 を、常に100を返す関数に置き換える myapp.utils.func1 = Mock(return_value=100) 戻り値が定数でない場合は、Mock()にside_effec
菊地時夫先生への、GNU Mailmanコミュニティからのメッセージ - atsuoishimoto's diary
すでにご存じの方も多いと思いますが、PythonやApache、Mailmanなど、様々なオープンソースコミュニティで活躍なさっていた、元高知大の菊地時夫 名誉教授が、平成２４年１月１４日にお亡くなりになりました。 菊地先生はGNU Mailmanという、メーリングリストを運営するソフトウエアの国際化・日本語対応で大変大きな活躍をなさっておりました。GNU Mailmanはこの種のソフトウエアではおそらく最大のシェアを占めており、日本語でメールを利用されている方ならば、知らないうちに菊地先生の貢献の恩恵を受けている可能性は非常に高いのではないかと思います。 今回、菊地先生の訃報にあたり、GNU Mailmanの開発者から弔辞が寄せられました。 http://wiki.list.org/display/COM/TokioKikuchi 以下に、このページの拙訳を掲載します。 去る2012年1
BeProudさんで草鞋を脱ぐ - atsuoishimoto's diary
まだ100%確定という訳ではないが、著名なPython企業である BeProud さんで、11月からお仕事をさせていただくことになりそうだ。ちょっとお話でも、という事でお邪魔させていただいたら、なかなか面白そうな案件を伺って、決めてきてしまった。自分でもちょっと意外な展開である。 草鞋を脱ぐとは言っても、当面はバイト待遇で、と言うことでお願いした。なんでバイトかといえば、今後の進路を決めかねているというのもあるが、主にBeProudでちゃんと仕事ができるか、今ひとつ自信がないためだ。普通の受託開発でプロジェクトに参加するのは本当に久しぶりで、自分の中で調整して勘を取り戻すのに、色々と時間がかかりそうな気がするのだ。 ということで心配な面もあるのだが、それでもBeProudで働けるのは楽しみで、不安感とか緊張はあまり感じない。なにしろ、現在でも私のTwitterのタイムラインはBeProud
uniq()あれこれ - atsuoishimoto's diary
ふとこちらの記事を拝見して、頭に浮かんだことをメモってみる。 id:aroma_blackさんの [y for x,y in enumerate(seq) if seq[:x+1].count(y) == 1] や、id:cocoatomoさんの [x for i, x in enumerate(a) if i == a.index(x)] でも良いんだけど、あえて別解を探すと： Python2.7/3なら import collections list(collections.OrderedDict((x,None) for x in seq).keys()) 一番素直で速いのは filter(lambda x,s=set():(x not in s, s.add(x))[0], seq) かなぁ？ 入力のリストの要素から、新たな一つのリストに還元すると考えれば、reduceを使う手もあ
許されざる悪事 - atsuoishimoto's diary
djangoの中に、こんな処理がある。 def get_cache(backend_uri): scheme, host, params = parse_backend_uri(backend_uri) … … … return getattr(module, 'CacheClass')(host, params) cache = get_cache(settings.CACHE_BACKEND) (http://code.djangoproject.com/browser/django/trunk/django/core/cache/__init__.py) 私はこの cache = get_cache(settings.CACHE_BACKEND) を許さない。モジュールのグローバルスコープで、他のモジュールの値を参照するという悪行を許すことはできない。 この行は、どこかで impor
オープンソースstackoverflowクローン OSQA - atsuoishimoto's diary
IT技術者の皆さんなら、Stack Overflow というサイトをご存じだろう。いわゆるQ&Aサイトだが、非常に使い勝手の良いサービスで、この手のサイトにはあまり足を運ばないようなプログラマでも、ここでは書き込んでいるのを見かけることも多い。 Stack Overflowのクローンサイトを構築するアプリはいくつかリリースされているのだが、今回、その中から OSQA というアプリを日本語化したので、ついでにサイトを立ち上げてみた。 http://answer.pythonpath.jp ドメイン名はpytonpath.jpだが、Python関係なく質問・回答を寄せていただきたい。プログラミングやシステム管理などに関するものであれば、なんでもOKだ。 掲示板との違い これはいわゆる掲示板サービスではないし、「Yahoo知恵袋」のようなQ&Aサービスともちょっと違う。単に質問と回答を繰り返すの
メソッドオブジェクトの不思議とid()の落とし穴 - atsuoishimoto's diary
さて、@aroma_blackさんがこんなスクリプトで悩んでおられたのである。 class C(object): def foo(self): pass c = C() print id(c.foo) == id(c.__class__.foo) print c.foo is c.__class__.foo @aroma_blackさんはメソッドオブジェクトがどこに隠れているのか調べていたようだ。この二つのprint文で出力される結果はおわかりだろうか。 c.foo is c.__class__.foo まず、二番目のprint文から見てみよう。 c.fooは見た通り、Cクラスのインスタンス c からメソッド foo を取得する式である。 >>> c.foo <bound method C.foo of <__main__.C object at 0x02A8B3B0>> c.fooでは、
Python2のstrは死んだ - atsuoishimoto's diary
Python3の概略をざっと聞くと、Python3ではPython2のユニコード型が文字列型になり、文字列型はバイト文字列型になった、というイメージを持ってしまう人も多いだろう。Python2の s="spamspamspam" は、Python3の s=b"spamspamspam" と同じだ、と。 しかし、Python3に"バイト文字列"なんて存在しない。あるのは "bytes"だ。複数形を示す "s"に注意しよう。bytesはバイトのコンテナであり、バイトとは整数値だ。バイトは文字ですらないのだ。 そう、だからもう認めよう。Python2のstrは死んだ。Python3にはもう存在しない。strは消え去った。お亡くなりになった。お隠れになった。成仏した。主の御許に召された。バージョン履歴に残るゴミクズとなった。その生涯は幕を閉じ、アンコールに応じることもないのである。 strとbyt
internのひみつ - atsuoishimoto's diary
Pythonにはintern()という組み込み関数がある。結構特別扱いで重要な組み込み関数なのだが、使い道が今ひとつ分かりにくいのか知らない人も多いようだ。 intern <捕虜･危険人物などを>(一定の区域内に)拘禁する, 抑留する. [新英和（第７版）・和英（第５版）中辞典 株式会社研究社] なんだか物騒な関数だが、同じような機能を持つLisp族の関数から名前を拝借したのだろう。intern()をPythonスクリプトで書くと、だいたいこんな感じの処理になる。 _intern_map = {} def intern(s): if s in _intern_map: return _intern_map[s] else: _intern_map[s] = s s.interned = True return s 文字列sと同じ文字列が専用の辞書_intern_mapに登録済みなら登録済み
プログラミングを学んでみたい人に - atsuoishimoto's diary
Twitterなんかをいろいろ眺めていると、もどかしくってたまらなくなってしまうことがある。プログラミングをやってみたいな〜と思いながらも、いつまでも最初の一歩を踏み出せない、そんな人を見たときだ。踏み出してはみたものの、自分の進路に自信を持てなくて先に進めなくなっている人も多い。見かけるたびに、もどかしさのあまり身もだえしている。 世の中にはいろんな技術があるが、プログラミングという技術はダントツに入門しやすい部類だ。必要な設備はパソコン一台だけだし、数学の知識も最低限で問題ないし、肉体的な鍛錬も必要ない。勘の良い人なら、１週間もあればそこそこ基礎を学べてしまう。その程度の勉強でも、それなりに実用的なプログラムを書けたりするのだ。まずは始めてみようよ、といつも思う。 実際にプログラミングを始められない理由として、最初に学ぶプログラミング言語の選択に迷っている人は多いみたいだ。確かに色々な
is演算子のふしぎ - atsuoishimoto's diary
Pythonには、二つのオブジェクトが同じオブジェクトかどうか判定する is演算子というのがある。==演算子とちょっと似ているが、==演算子は二つのオブジェクトの値が等しいかどうかを判定し、is演算子は値に関わらず異なるオブジェクトが指定されればFalseを返す。 >>> list1 = [1,2,3] >>> also_list1 = list1 >>> list2 = [2,3,4] >>> equal_to_list1 = [1,2,3] >>> list1 is also_list1 # list1 と also_list1 は同じオブジェクト True >>> list1 is list2 # list1 と list2 は異なるオブジェクト False >>> list1 == list2 # list1 と list2 は異なる値を持つ False >>> list1 is
Pythonバージョンの選びかた - atsuoishimoto's diary
Pythonはおよそ18ヶ月ごとに新しいメジャーバージョンをリリースする慣習になっていて、これまでにたくさんのバージョンがリリースされ、広く利用されてきた。Pythonの開発では後方互換性を保つことが非常に重視されていて、通常のアプリケーションであれば、Pythonのアップデートで動かなくなってしまうことはあまりない。アプリケーションが今後廃止される予定になっている機能を利用していると、DeprecationWarningという警告が出力されてしまう程度だ。 DeprecationWarningが出るようになってから実際に廃止されるまで少なくとも数年間はあるので、普通はその間にのんびり対処する事ができる。また、いったん廃止予定と決定されても、その機能が一部で使い続けられている場合には実際には削除されない、というケースも非常に多い。Pythonのドキュメントを見てみると、もう10年も前から廃
func_closureのひみつ - atsuoishimoto's diary
Pythonでデコレータで修飾した関数から、修飾される前の関数を取り出したいというニーズは多いようで デコレータ式を適用した関数から元の関数名を探す - gumi Engineer’s Blog デコレータを外す - logiqboard デコレータを取り除いて見たかった。 - podhmoの日記 のようなブログエントリが上がっているが、Pythonでは元の関数を取り出す確実な手法は用意されていないので諦めていただきたい。デコレータを使って関数を定義しても、Pythonはその情報をどこにも記録していない。 必要であれば http://docs.pylonsproject.org/projects/venusian/dev/ のようにデコレータ自身に細工をする、テスト対象モジュールのインポート時にフックを入れ、修飾せずに元の関数を返すデコレータに置き換えるなどとするしかないだろう。 自由変数
UnicodeDecodeError/UnicodeEncodeErrorに悩まないPython 2.x プログラミング - atsuoishimoto's diary
最近、ときどきTwitterで「Python」を検索して眺めていたのだが、Pythonの分かりにくいところとして「UnicodeDecodeErrorが出てうざい」という不満をよく見かけるようだ。 確かに、Pythonでは、数字やアルファベット以外のユニコード文字を使おうとすると、対応する処理を書かなければUnicodeEncodeErrorやUnicodeDecodeErrorが出てしまう。Python3では色々改善されているのだが、Python2では分かりにくい点も多い。 このUnicodeDecodeErrorを見て、「Pythonは日本語が苦手だ」と考えてしまう人も多いだろう。確かにそう思ってしまっても仕方がないが、それは正しくない。日本人だけでなく、アメリカ人でもフランス人でもドイツ人でも、ユニコードを使う時はみんな等しく平等にこのエラーを出しているのである。 もちろん、慣れてし
Pythonで学ぶ「詳解 UNIXプログラミング」(その0) - atsuoishimoto's diary
お勧めのUNIXプログラミングの入門書は？と聞かれれば誰もが挙げるであろう名著 W.リチャード スティーヴンスの詳解 UNIXプログラミング(APUE)。必読書と言っても良いだろう。 "Pythonで学ぶ「詳解 UNIXプログラミング」"シリーズのエントリでは、私自身の復習もかねて、APUEで解説されているサンプルを、Pythonで実装してみたい。 以降の解説では、特に断り書きのない限り ピアソン・エデュケーション社出版の詳解 UNIXプログラミング 新装版をもとに、Ubuntu Linux 10.10上のPython2.7を対象に解説する。他のUNIX/Linuxや異なるバージョンのPythonであっても、ほとんどそのまま流用できるはずだ。 サンプルコードの背景などの解説は行わないので、かならず「詳解 UNIXプログラミング」とあわせて読んでいただきたい。 ところで、APUEの第2版が2
James Gosling Interview about Java - atsuoishimoto's diary
2011年1月1日に、IEEEの "Computer"マガジンは James Gosling にインタビューを行った。インタビュアーは、Gosling が作った言語(訳注：もちろんJavaのこと)を用いてのオブジェクト指向デザインに関して、この21年間を回顧するインタビューが取れるものと思っていた。しかし、インタビューが進むに連れ、もともと取材しようとしてたものよりも衝撃的な記事を得ることになった。その後、業界への衝撃が強すぎるとして、 編集者はその取材記事をボツにしたが、 こういうものには情報のリークが付き物である。 以下、インタビューの生の記録をお届けする。編集を行っておらず、またぶっつけ本番であるため、原稿のあるインタビューのようにはきちんとしていないが、きっと読者は興味を感じてくれるものと思う… 尚、このインタビューの背景を正しく理解するために、同じインタビュアーによる Bjarn
あなたの知らないPythonのひみつ - atsuoishimoto's diary
Pythonでは、ループ・try・withブロックは最大20までしかネストできない。 >>> def spam(): ... while 1: ... while 2: ... while 3: ... while 4: ... while 5: ... while 6: ... while 7: ... while 8: ... while 9: ... while 10: ... while 11: ... while 12: ... while 13: ... while 14: ... while 15: ... while 16: ... while 17: ... while 18: ... while 19: ... while 20: ... while 21: ... print "Deep!" ... SystemError: too many statically n
【お詫びして訂正】Pythonの粗大ゴミ - atsuoishimoto's diary
昨夜、Pythonの粗大ゴミというエントリを書いたが、このエントリを公開し、風呂に入ってさて寝ようとした時、ふと気になったことがあった。try-finally付きのジェネレータがgcで解放されないのなら、withブロックも一緒ではないだろうか？ あの記事は昔ジェネレータでtry-finallyが使えるようになった時（そう、最初はジェネレータ内でtry-finallyを使うとコンパイルエラーだったのだ）、ふと気になって調べた記憶を元に書いた。あの頃はたぶんまだwith文が無かった頃なので、withブロック中での動きは把握していない。 で、調べてみると、やっぱりwithブロック中のジェネレータオブジェクトが循環参照に含まれていると、try-finallyの場合と同様に解放されない事がわかった。次のようなジェネレータ def uncollectable(arg): with context: y
Pythonのガベージコレクタは「マーク&スイープ」？ - atsuoishimoto's diary
昨日公開した Pythonのガベージコレクション にこんな突っ込みをいただいた。 マークアンドスイープGCじゃないそうです PythonのGarbageCollection http://www.narihiro.info/translate/garbage_collection_for_python_jp.html 確かに、Pythonで使用しているのは教科書で言うマーク&スイープとは異なるアルゴリズムである。上記のページにあるように、いわゆるマーク&スイープは、ルートオブジェクトと呼ばれる生きていることが確実なオブジェクトを見つけ出し、そこから参照されているオブジェクトをどんどん探り出して、最終的に誰からも参照されていないオブジェクトをあぶり出すというものだ。Pythonではルートからオブジェクトを探すというアプローチを取っておらず、私も会場の説明では「マークアンドスイープの一種」のよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
