)
次世代標準非同期I/Oフレームワーク asyncio (Tulip) - methaneのブログ
Python Advent Calendar 2013 の4日目です。 Python 3.4 で標準ライブラリに追加される asyncio を触ってみます。 なお、 Tulip とは asyncio のリファレンス実装のプロジェクト名です。 背景 Python はよく非同期 I/O プログラミングに使われます。 Twisted, Tornado, gevent, eventlet, pyuv などのフレームワークがあります。 これらのフレームワークの問題点として、ライブラリの再利用性の低さが挙げられます。 たとえば Twisted 用に書かれた XMPP ライブラリは、そのままでは Tornado で 利用することができません。 この問題の解決策として、良くイベントループの乗り入れが行われます。 GUIアプリケーションに組み込む場合などを考えて、多くのフレームワークが最初から イベントルー
Python のカッコ無いところを紹介してみる - methaneのブログ
Haskellのカッコいいところを紹介してみる をみて、 Python と比較してみようと思います。 以下、 heading は上記記事の heading の引用で、 Python のことではなく Haskell の特徴です。 数学や英語の知識で「読める」表現が多い 一応、 instanceof など多くの2引数関数が、 infix で書いたら左に来るものが第一引数というルールを守っているので、頭の中ではそれで引数の順序を補完して、 if instanceof(x, int) は "if x is instance of int" と読んでいます。引数の順序がどっちだっけ？と迷うことはほとんど無いです。 しかし残念ながら Python は中置記法はありません。構文をシンプルに保つ方を取っているんでしょうね。 import Data.List import Data.Function xs
[python] 優れた Python プログラマを見分ける10+1の質問 - methaneのブログ
お詫びと追記 この記事は 「優れたPerlプログラマを見分ける27の質問」の日本語訳 - Islands in the byte stream を見て書いたものですが、僕が Perl について無知なのとタイトルに釣られたために、で元の問題の意図を汲み取れていませんでした。 その言語に取って重要な基本事項を理解しているかのチェックリストとしては、以下の質問は不適切です。 お詫びに、真面目に Python の基本事項に対するチェックリストをつくろうと思います。 質問 一般 バージョン管理をしているか テストを書いているか 1つ以上のオープンソースプロジェクトのコミッタであるか Python言語について list, tuple, dict, deque, heapq, bisect がどういう場面に適しているか説明しなさい ジェネレータの利点を説明しなさい Python 2 プロジェクトの Py
![[python] 優れた Python プログラマを見分ける10+1の質問 - methaneのブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ff51f2ad0894c65eb167d7712a3112cda8bf889/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929890341541%2F12704591929890341604%2F1348037597)
Pythonの配列操作 - methaneのブログ
いまさらだけど、 http://0xcc.net/blog/archives/000043.html の Python の部分を添削。 len(a) == 0 は、 if a: のようにリスト自体が空の時に偽になるので使わない。 a.pop(0) は del a[0] とも書ける。どちらでも良いが、多分属性参照が無い分 del の方が高速 a[:] = [] も同じく del a[:] a.remove(x) ※最初の一つしか削除されない は、すべてのxを削除したいなら a = [y for y in a if y != x] del(a[i]) は、 del が関数ではないので del a[i] と書く。 Ruby の a.uniq は、ソート済みに対する操作じゃないよね？ 重複を削除するだけなら set(a) でいけるけど、順序の保存が必要なら z = []; for x in a:
継続のすばらしさ - methaneのブログ
Haskellでやると書いておいて、Pythonでやっちゃう罠。 Pythonがサポートしている中途半端な継続ことgeneratorでsortすれば、遅延評価と同じく、「先頭n個だけ使う」という用途では後半のsortを実行しないで済む。 >>> l = [3,5,2,1,4,5,8,2] >>> def lazy_sort(lst): if len(lst) == 0: return mid = lst[0] left = [] right= [] for v in lst[1:]: if v < mid: left.append(v) else: right.append(v) lg = lazy_sort(left) for y in lg: yield y yield mid rg = lazy_sort(right) for y in rg: yield y >>> s = laz
Pythonの次のバージョン管理システムがMercurialに決定 - methaneのブログ
１年くらい前から、マスターのSubversionとミラーのMercurial/Bazaar/Gitを運用して、Subversionの次のSCMを選んでいたPython。 Gitはもっと前に却下されていたんだけど、とうとう今日、GuidoがMercurialに決定したとMLでアナウンスした。理由は、 Mercurialの方が(Guidoの回りで)人気が高い Subversionユーザーの移行が楽 多くのオペレーションでMercurialの方が速い 個人的にMercurialは捨ててBazaarメインにしていってたので残念。オペレーションに関しては、1.9くらいから大分Bazaarも早くなったんだけどなぁ。 Mercurialをやめてたのは、ファイル名をUnicodeにしないかというあたりのMLの流れから。反対派が「ファイル名はバイト列だ！」と主張していた根拠は、Makefile等たくさんのフ
len が関数になっている理由 - methaneのブログ
http://d.hatena.ne.jp/pashango_p/20090702/1246550203 len()がリストのメソッドでないのも同じ理由です。 オブジェクト指向的に考えれば、リストのメソッドであるべきなのに、わざわざビルトイン関数にしたんです。 「オブジェクト指向的に考えれば、リストのメソッドであるべき」って感じで、オブジェクト信者はそれが正義みたいに考えちゃうんだろうね･･･ Pythonは合理主義。「オブジェクト指向的に○○」よりも、一貫した少なくて明確なルールを重視する。 len() が .length() メソッドだったらどうなるか。あるコンテナは .length() の代わりに、 .len() や .size() という名前を使ってしまうかもしれない。「サイズを取るメソッドは.length()」という 暗黙のルールができてしまい、そのルールが頭に入っていない人が一
Pythonは他の言語の慣習の持ち込みを嫌う - methaneのブログ
拡張引用構文覚えた！ こういう経験があると、たかが「List = list」ごときで何を大げさなと思ってしまうけど、Pythonista的にはこういうのも受け入れられないんだろう。 Pythonistaはtypedefすら拒絶する? (Re: Python での組み込み型をより自然な名前にする) - kなんとかの日記 Pythonは一貫性を重視する言語なので、他の言語の慣習を持ち込んで一貫性を崩すことに対するアレルギー反応が強い。 前にも書いたけど、Pythonのtype名が小文字始まりであることについては、特に技術的な利点とかそういうのがあるわけじゃなくて、単に最初の仕様がそうであって、それがそのまま継続されているっていうだけだよね? (違ってたら教えてください) だから大文字始まりのエイリアスを作るぐらい、そんなに目くじらを立てることとは思えない。それなら「typedef unsign
勝手に採点 (Re: 自分ならこう書く - pythonでA*) - methaneのブログ
自分ならこう書く - pythonでA* - ラシウラより def astar(init, goal, nexts, distance=lambda path: len(path), heuristic=lambda pos: 0): import heapq queue = [] checked = [init] heapq.heappush(queue, (distance([init]) + heuristic(init), [init])) while len(queue) > 0: score, path = heapq.heappop(queue) last = path[-1] if last == goal: return path for pos in nexts(last): if pos in checked: continue checked.append(pos)
そんなに Array.join がいいのか - methaneのブログ
「(ruby|javascript)でstr.join(array)、pythonでlist.join(str)」http://blog.livedoor.jp/dankogai/archives/51226075.html ここではlistを継承したListクラスをこさえて、そこにjoinメソッドを追加しているが、listに直にメソッド追加する方法はないのだろうか.... 多分できない。 PythonはPerl,Rubyに比べて、上の方は同じくらい柔らかいんだけど、下の方は堅い。 Unicodeのことまで考慮に入れて実装したために、実装がずいぶんと泥臭いものになっている。 join したいものが一種類ではないというのが、 join が list のメソッドでない理由の一つだからね。 str()はUnicodeを食うと例外をお吐きになる。それでいて"dankogai" + u"小飼弾"はu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
