uvとRye - methaneのブログ
先週にRuffを開発しているAstralがuvを発表しました。 astral.sh uvは現在のところはvenv, pip, pip-toolsの基本的な機能を提供していますが、将来は"Cargo for Python"になることを目標にしています。 一見すると乱立しているPythonのパッケージ管理ツールにもう一つ加わったように見えますが、Ryeの開発者のArminとuvの開発チームは連携していて、同時に次のような発表をしています。 uv: Python packaging in Rust Rye Grows With UV | Armin Ronacher's Thoughts and Writings Ryeはもともとより良いパッケージツールがどうあるべきかの実証のために作られていて、中身は既存のツールのツギハギだった Ryeがpip-toolsやvirtualenvの代わりにuvを
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つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ
構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
