pyenvを初心者に薦めるのはもうやめよう - methaneのブログ
Pythonのパッケージ・プロジェクト管理ツールはまだ乱立状態にあって、どれを使えばいいのかわからないから慣れたpyenv+pipを使おうという判断をする人がいるかもしれない。その判断自体は別に否定しないけれども、初心者に教える時にpyenvを教えるのはもうそろそろやめてほしい。 Pythonをソースからビルドするので、コンパイラや依存ライブラリを事前に揃えないといけない。依存ライブラリが足りないと中途半端なPython環境もできうる。 デフォルトで最適化オプション(PGO+LTO)が付いてないので、最適化ビルドしたPythonより~5%程度遅い Windowsで使えない Rye, pdm, Hatch などは python-build-standalone と呼ばれるビルド済みPythonをインストールする機能があるので、これらの欠点が存在しない。 Pythonをインストールするところま
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
Python 3.11 からデフォルトの文字列ハッシュアルゴリズムが SipHash13 になります - methaneのブログ
Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。 その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。 https://github.com/rust-lang/rust/issues/29754 https://bugs.ruby-lang.org/issues/13017 Python でもSipHash13に切り替えようという提案を2017年に行っていたのですが、実装した人がなかなかプルリクエストを作ってくれず、またPythonは文字列がimmutableでハッシュ値をキャッシュしているためにそこまで大きなインパクトがなかったこともあり、ずっと放置されてい
PEP 8騒動について - methaneのブログ
今週PEP 8の小さい変更についてMLで騒動が起こってしまいました。 該当のコミットはこれです。 PEP 8: Change requirement to adhere to Standard English (#1470) · python/peps@0c6427d · GitHub 変更点はごくごくシンプルなものです。 - When writing English, follow Strunk and White. + Ensure that your comments are clear and easily understandable to other + speakers of the language you are writing in. 今まで知らなかったのですが、変更前の "Strunk and White" とは The Elements of Style というすご
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 を始めました
3月1日、Homebrew のデフォルトの Python が Python 3 になります。 - methaneのブログ
以前からアナウンスされていた 通り、 3/1 （日本時間では 3/2 になるかも）にデフォルトの Python が Python 3 に切り替わる予定です。 現在そのプルリクエストがレビュー中です。 github.com 具体的には、今まで "python" という formula は Python2.7 でしたが Python 3.6 になります。 Python 2 をインストールするには brew install python2 もしくは brew install python@2 とします。（これまで使えていた python3 という Formula は python への alias になります。） 何らかの理由で意図的に Python 2 を選択しているユーザー以外は、 brew install python で（推奨される）Python 3をインストールできるようになるので、こ
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の適用範囲を広げるためにジェネリクスを含めて機能追加も検討し始めようかっていうフェーズです。 あとどの言語にもちょっと公平的な見方ができなくなった痛いファンはいるもので、そういった人たちをいちいちあげつらってこういう言い方で失笑するのは、別に止めはしないけど自分の格を下げるだけだと思う。
)
次世代標準非同期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アプリケーションに組み込む場合などを考えて、多くのフレームワークが最初から イベントルー
CPython の Core Developer になりました - methaneのブログ
Python 3.6 に取り込まれた dict の新実装などでコアコミッターに興味を持ってもらい、 Core Developer (要するにコミッター) に推薦しようか？という提案をもらいました。 最初はコミッターとか面倒そうだし、コミットメッセージとかNEWSエントリー（通常パッチをコミットするときにコミッターが書く）とかを英語で書くのも英語が得意な人がやったほうがいいだろうし、とりあえず github に移行するまでは様子見しておこうと思ってたのですが、 dict 関係のパッチがいくつもレビュー待ちでなかなかコミットされないのを見て「やっぱりアクティブなコミッターが全然足りてない」と考え直し、志願することに。 で、先月末にコミット権をもらった（というか push できる権限を持った hg アカウントに ssh 鍵を登録してもらった）のですが、新米コミッターは簡単なパッチでも他のコアコミ
Python 3.6 の（個人的に）注目の変更点 - methaneのブログ
Python 3.6b1 がリリースされましたね。（フライング） beta1 ということで、 3.6 に向けた新機能の追加は (provisional package を除いて) 終了です。ただし、仕様が確定したと言うわけではなくて、beta版に対するフィードバックを元に新機能を修正したり、最悪 revert して 3.7 に持ち越しにされる可能性もあります。 なお、 3.6b1 が出る前の1週間が core dev sprint があり、そこでめちゃくちゃ大量に大きめの変更が入りました。なので、常用環境には全くオススメできませんが、OSS開発者だったら .travis.yml に python: "nightly" を追加してリグレッションの発見に貢献したり（←これめっちゃ有り難いです）、それ以外の人も 3.6 を試してみて早めにフィードバックをしてもらえると、年末の 3.6 がより完成
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 を実装していましたが、
CPython の GC チューニング - methaneのブログ
ISUCON は Go で参戦しているんだけど、複数のチームが Python で予選通過したらしいので、応援のために Tips を公開していこうと思う。 目次 CPython の GC について 統計情報を出力する 第一世代GCの間隔を調整する Out of Band GC 循環参照を見つけて対処する CPython の GC について CPython のGCは参照カウント＋循環参照コレクタだ。そして参照カウント方式は(幾つかの欠点はあるものの)Webアプリのボトルネックになったりはしにくい。 なのでGCチューニングの基本は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代
Python の新しいプロファイラ vmprof が面白い - methaneのブログ
PyPy 2.6 と同時に、 vmprof という CPython/PyPy 用のプロファイラが登場しました。 私はまだ PyPy では使っていませんが、CPythonのプロジェクトをこれでプロファイル取ってみたらなかなか面白かったので紹介します。 概要 Python にはもともと標準ライブラリとしてプロファイラ (cProfile) が付いてきていますが、これは関数の呼び出しと戻りでコールバック関数を呼び出しつつ実行時間を計測するタイプのプロファイラで、短時間でも正確なプロファイルが取れる反面、オーバーヘッドが大きく、小さい関数をたくさん呼び出す部分がオーバーヘッドでより大きく見えてしまうなどの問題がありました。 これと別の種類のプロファイラとして、定期的にサンプリングして、サンプルが多いところが実行時間も多いハズ、というプロファイラもあります。こちらはある程度の量のサンプルを集めないと
len が py3k でも 関数のままである理由 - methaneのブログ
結局は http://d.hatena.ne.jp/methane/20090702/1246556675 なんだけど、ソースを提示しておく。 まず、Python FAQにはこんな風に書いてある。 http://www.python.org/doc/faq/general/#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list The major reason is history. Functions were used for those operations that were generic for a group of types and which were intended to work even for objects t
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 のサポートを切れる時期なので、思い当たる人は目を通してお
Flaskの闇 - methaneのブログ
Merry, Xmas. Python advent calendar 2012 (#python_adv) 24日目の記事を、ミクパの再放送をBGMにお送りします。 今日は Flask のイケてないところとのつきあいかたを紹介します。 循環 import 問題 app.py １ファイルだけの構成から成長してファイルを分け始めるときに突き当たるのが循環import問題です。 今まで１モジュールだった app.py を myapp/__init__.py にして、 view 関数を myapp/views.py の中で定義していきたいとします。 #myapp/__init__.py from flask import Flask app = Flask(__name__) import myapp.views #myapp/views.py from myapp import app @ap
)
Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ
id:kazeburo さんが Gazelle という高速な Perl 用の Web アプリケーションサーバーを公開されました。 Gazelle - Plack Handler for performance freaks #yokohamapm from Masahiro Nagano Gazelle の特徴のうち幾つかは、 id:mopemope 作の Meinheld と同じです。 IO周りは全てCで書かれている accept4 や writev などの Linux 独自のシステムコールを利用している 一方で異なる点もあります。 Meinheld は HTTP/1.1 に対応していて、 keep-alive が利用できる。 Meinheld は greenlet というコルーチンを利用して、 long polling や SSE に対応している。 Meinheld が http-pa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
