Go が for ループをやめるために足りないもの - methaneのブログ
ジェネリクスの話題になると常に出てくるのが、 for ループの代わりに関数型スタイルで書きたいという要望です。 for ループで書くのは、可読性が悪く、筋力がいるとまで言う人もいます。 しかし、ジェネリクスが追加されても、このスタイルのプログラミングは実用的にはなりません。ジェネリクス以外にも足りない部分がたくさんあるのです。 例えば、次のようなコードを考えてみましょう。 type PointLog struct { ID int64 UserID int64 Point int32 } // 今の書き方 func UserTotalScore(log []PointLog, userID int64) int64 { var t int64 = 0 for _, p := range log { if p.UserID == userID { t += int64(p.Point) }
Re: Re: Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ
kmizu.hatenablog.com Twitterである程度レスをしたのですが、やはり繰り返される話題なので残る形で書いておきたいと思います。 Goユーザーの中で、ジェネリクスがなくても構わないと主張するユーザーへの批判はしたけど、Goユーザー全てがそうだと思っているわけではない Goユーザーの中でジェネリクス不要論を唱えているユーザーへの批判はしたけど、そういうユーザーを馬鹿にしているわけではない 私の前の記事は、まさに前者の批判に対する返答です。私はGoにジェネリクスを追加することに賛成ですが、別にそうならなかったとしても失望しない程度に「なくても構わない」人です。 一方で後者は、もしGoに限らず一般論としてのジェネリクス不要論だとすれば、批判にも値しないと思いますよ。話題にするつもりはありません。 Goは特に今で言うマイクロサービス的なものを（色んな意味で）効率よく開発するため
Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ
なんども繰り返される話でうんざりなんだけど、繰り返されるたびに反論するのもアレなので、URL貼れるように記事にしておく。 Goが頑なにジェネリクスいらないというだけ他の言語勢から失笑買ってるというのは自覚して— {{alert()}} (@mizchi) 2017年9月19日 頑なに要らないと言ってる人が具体的にどの発言のことを差してるのか分からないけど、コア開発者たちはツールチェインやランタイムの進化を優先していただけで頑なに拒否してたりはしません。今はツールチェインやランタイムが大分進化したから、Goの適用範囲を広げるためにジェネリクスを含めて機能追加も検討し始めようかっていうフェーズです。 あとどの言語にもちょっと公平的な見方ができなくなった痛いファンはいるもので、そういった人たちをいちいちあげつらってこういう言い方で失笑するのは、別に止めはしないけど自分の格を下げるだけだと思う。
pip 9.1 から msgpack が使われるようです - methaneのブログ
Adopt cachecontrol 0.12.0 with msgpack support というコミットがありました。 どうやら CacheControl というのが pip が使っている requests 用のキャッシュライブラリで、その最新版が msgpack を使っているようです。 前のバージョンはバイナリデータを base64 した上で json に入れて gzip していたのですが、もともと圧縮されてるバイナリを扱うときに gzip は base64 によって増えた分を減らす以上の効果は期待できない上、 PyPI からダウンロードするファイルってほぼ100%圧縮済みなので、キャッシュファイルの読み書きで無駄なオーバーヘッドがあったみたいですね。 バンドルされてる msgpack は pure Python で実行できる fallback モジュールのみなのでどこでも動くし、
Python と Ruby と typing - methaneのブログ
うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました
依存するパッケージは厳選しよう - methaneのブログ
japan.zdnet.com JS界隈が大騒ぎになった事件だけど、こういった事件自体は完全に防ぐことは不可能だと思う。 今回は依存ライブラリが削除されるだけで済んだけど、 npm install するだけで ~/.ssh ディレクトリを zip にしてどこかに送信するような悪質な攻撃であれば、単にCIが止まるどころでなく、世界中のエンジニアの秘密鍵がばらまかれてあちこちのサーバーにssh可能な事態になったわけで、そんな悪質な攻撃を bugfix なマイクロバージョンアップとして公開される事もありえたわけだ。 第三者のパッケージに依存するということは、それだけのリスクを背負い込むということだ。だが、逆に外部のライブラリに依存しないようにすると、生産性が落ちてしまう。 なので、コードを読む、信頼できるメンテナの公開しているパッケージを選ぶなどといった方法で、リスクとメリットのバランスを取って
prompt_toolkit がアツい - methaneのブログ
とりあえず mycli と aws-shell のスクリーンキャストを見てください。 prompt_toolkit はこのようなリッチコンソールアプリを作るためのライブラリです。 Windows でも動きます。 Jupyter (ipython notebook) を切り離した、コンソール版の ipython も次のメジャーバージョンでは readline ベースから prompt_toolkit ベースに作りなおされています。 ipython 以外にも ptpython というシェルもあり、 ipython の各種 magic が不要な場合はこちらで十分でしょう。 https://github.com/jonathanslenders/python-prompt-toolkit#projects-using-prompt-toolkit には、他にも prompt_toolkit を採用
bzrのリポジトリをgitに変換する方法 (fast-import編) - methaneのブログ
bzr-git を使う以外に、 fast-import を使う方法があります。 単に乗り換えるために変換したい場合は、こちらのほうが高速で楽です。 まずは、 bzr の fastimport プラグインを用意します。 $ pip install fastimport $ cd ~/.bazaar/plugins $ bzr branch lp:bzr-fastimport fastimport次に、ブランチを変換していきます。カレントディレクトリ配下に trunk release という2つの bzr ブランチがあるとします。これを proj.git に変換します。 $ git init proj.git $ cd proj.git $ bzr fast-export --export-marks=marks.bzr ../trunk | git fast-import --export-
Python を速くする取り組み - methaneのブログ
速い Python 実装といえば PyPy が有名ですが、 Python 3 へのキャッチアップが遅い、 CPython が持っている Python/C API のサポートがまだ弱く遅い、などの欠点があります。 また、 Google の1年プロジェクトだった Unladen Swallow もありました。これは CPython をフォークして LLVM で JIT を実装するものでした。この fork 実装は終わりましたが、この時期まだ不安定だったLLVMへの貢献は大きく、（ちゃんとおってないので憶測ですが）現代LLVMを利用したJITを実装しているプロジェクトは全部間接的に Unladen Swallow の成果の上に成り立っていると言えるかもしれません。 終了した JIT プロジェクトといえば、 psyco もありました。これはベタに CPython の JIT を実装していましたが、
Python 3.3 以上で使える Python/C API で文字列アクセスを高速化 - methaneのブログ
試しに英語で Blog を書いてみた のですが、書くので精一杯で結局何が言いたいのか分からない感じになってしまったので今後は日本語 Blog 書いてから英訳しようと思います。 Python 3 は 3.2 まで、文字列を unicode に統一した関係で Python 2.7 に比べて遅くなったりメモリ効率が悪くなったりしてしまっていたのですが、 Python 3.3 で PEP 393 Flexible String Representation が導入されて改善されました。 PEP 393 は Python の内部だけではなく Python/C API にも変更を加えており、内部を理解しつつ新しい API を適切に使えば、バイト列と文字列の間の変換を行うような C 拡張を高速化することができます。 そろそろ Python 3.2 のサポートを切れる時期なので、思い当たる人は目を通してお
Python の WebSocket ライブラリ - methaneのブログ
ちょっと調べてみたら、想像してたよりもライブラリが充実していたので、各ライブラリの特徴をまとめておきます。 AutobahnPython Autobahn が Python 用にサーバー、クライアント用のライブラリを提供しています。 AutoBahn Python は Pure Python で Twisted に依存しています。 Twisted を使うなら Autobahn でいいのですが、そうでない場合は別のものを使う必要があります。 Autobahn は Python 用以外に JavaScript と Java(Android) 用にもライブラリを提供していて、また他の多くのプロジェクトでも利用されている WebSocket 用のテストスイートも提供しています。高品質な WebSocket ライブラリがいっぱい揃っているのは多分このテストスイートのおかげでしょう。 Tornado
テストコードがないコードだけが技術的負債じゃないよ - methaneのブログ
私は「レガシーコード改善ガイド」を読んだことがないのですが、世間的に「テストコードがないコードが技術的負債」という認識が広まっているようです。 レガシーコード改善ガイドを批判するつもりは全くありませんが、たんにその本の中で使われている「レガシーコード」の定義に一致する物だけが技術的負債だという考えには反対します。 技術的負債とは、将来必要とされるメンテナンスコストの期待値だと思います。全てのコードは、メンテナンスを放棄するまでは技術的負債です。一方、メンテナンスコストを差し引いた上でそのコードが将来生み出す利益の期待値が、そのコードの資産価値だと思います。テストコードがないコードでも、利益を出すなら正の資産になります。 もちろん、資産価値をより大きくするために、技術的負債を減らすことは良いことです。技術的負債を下げる＝メンテナンスコストを下げることで、テストはその有力な手段の一つです。他に
ropevim を使う - methaneのブログ
インストール に続いて、実際に rope を使い始めてみます。 とりあえず Flask アプリを題材に環境を作ってみます。 準備 $ mkvirtualenv flask $ pip install flask $ mkdir hello $ cd hello app.py を作ります import flask app = flask.Flask(__name__) @app.route('/') def index(): return 'hello world.' if __name__ == '__main__': app.run() プロジェクトのセットアップ :RopeProjectConfig というコマンドを実行すると、プロジェクトのルートディレクトリを聞かれる (デフォルトでは .) ので、そのままエンターキーを押すと、こんどはプロジェクトを作るかどうか (0. yes 1.
ropevimをインストールしてみる - methaneのブログ
rope とは Python で書かれた、 Python コードに対するリファクタリング等を行うためのモジュールで、主に IDE やテキストエディタに高度な Python のサポート機能を追加するために利用されています。 私はかなりのデフォルト教信者でたいてい IPython と最低限の設定をした vim だけでコードを弄っているのですが、 PyCharm を触ってみてやっぱりIDEの持ってる機能は便利だと実感したので手を出して見ることにしました。 この記事ではとりあえずインストールについてまとめてみます。 vimが利用している Python を確認する 私は主に MacBook で MacPorts の Python と、 Kaoriya-MacVim を使っています。 vim が利用している Python がどれかと、そのモジュール検索パスを調べるために、とりあえず vim のコマンド
Python で TDD してみる - methaneのブログ
RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tracebackをログに残す場合のお約束コード - methaneのブログ