タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 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 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
Python 3.15からデフォルトのエンコーディングがUTF-8になります - methaneのブログ
Pythonがファイルを開くときなどに使われるエンコーディングはロケール（WindowsではANSIコードページ）依存でした。 Unixの世界ではどんどんUTF-8ロケールが一般的になっている一方、WindowsのANSIコードページはなかなかUTF-8になりません。 そのために、Unixユーザーが open(filepath) のようにエンコーディングを指定しないままUTF-8を仮定するコードを気軽に書いてしまって、Windowsユーザーがエラーで困るといった問題が発生します。 また、Windowsでもメモ帳（Notepad.exe）やVSCodeはすでにUTF-8をデフォルトのエンコーディングで使用しています。ANSIコードページがUTF-8になるのを待っていたらどんどん周りの環境から置いていかれ、レガシー化してしまいます。 Pythonがデフォルトで利用するエンコーディングをWind
3行サマリー： アプリではなくOSが接触履歴を取っている 今のアプリはOSの接触履歴をONにするだけ。バグがあっても使わなければ問題ない (特に東京では)今週の接触履歴が今後役に立つ可能性がある とうとう接触確認アプリが公開されました。これで今までよりも圧倒的に効率的に、陽性者の接触者に検査を受けてもらうことができるようになるかもしれません。ワクチンが開発されるまでの間、コロナと戦うための最大の武器になるかもしれません。 www.mhlw.go.jp しかし、Bluetooth が有効になってないと起動しない、利用規約に同意しないでアプリを終了しても同意したことになってる、などのリリース前の準備が明らかに不足してるであろう問題が報告され、炎上しています。 大前提として、これらのバグの責任はもちろんリリースした厚生労働省とその委託先の会社、そしてリリースを急がせた政府にあり、ベースとなったO
Pythonのパッケージ・プロジェクト管理ツールはまだ乱立状態にあって、どれを使えばいいのかわからないから慣れたpyenv+pipを使おうという判断をする人がいるかもしれない。その判断自体は別に否定しないけれども、初心者に教える時にpyenvを教えるのはもうそろそろやめてほしい。 Pythonをソースからビルドするので、コンパイラや依存ライブラリを事前に揃えないといけない。依存ライブラリが足りないと中途半端なPython環境もできうる。 デフォルトで最適化オプション(PGO+LTO)が付いてないので、最適化ビルドしたPythonより~5%程度遅い Windowsで使えない Rye, pdm, Hatch などは python-build-standalone と呼ばれるビルド済みPythonをインストールする機能があるので、これらの欠点が存在しない。 Pythonをインストールするところま
構造化ログのプラクティスをあちこちで調べていたら、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 発明されたのはどこか分かりませんが、流行
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
今週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 3.11 までは、空文字でも64バイトのメモリを使用していました。(64bitプラットフォームの場合) Unicodeの内部表現のうち一番小さい PyASCIIObject 構造体が48バイトで、その構造体の後ろにASCII文字列が続きます。その文字列はNUL終端されているので、空文字列でも1バイト追加されて49バイトになります。 >>> sys.getsizeof("") 49 さらに小さいメモリブロックのアロケートをしているpymallocがメモリを（アライメントの関係で）16バイト単位で割り当てるので、49バイトのmallocでも64バイトが確保されてしまいます。 Python 3.12 からは、PyASCIIObject構造体から wchar_t* 表現をキャッシュするポインタが消え、40バイトになりました。それでASCIIで7文字までの文字列であれば48バイトに収ま
今までuWSGIをシングルスレッド、マルチプロセスで使っていたのだけれども、昔に比べて外部のAPI呼び出しが増えているのでマルチスレッド化を検討している。 uWSGI uWSGIでマルチスレッドを有効にした時は、各workerスレッドがacceptする形で動作する。スレッド数以上の接続をacceptすることがないので安心。 プロセス内のスレッド間ではmutexで排他されて、同時にacceptを実行するのは1スレッドのみに制限されている。つまりthendering herd問題はプロセス間でしか起こらない。マルチスレッド化でプロセス数はむしろCPUコア数まで減らせるので、thendering herd問題はむしろ今よりも軽減できる。（ちなみにプロセス間でもロックしてthendering herdを許さないオプションもあるけど、プロセス間同期は怖いので使っていなかった。） ただしuWSGIのマ
Python がテキストファイルを開く時のデフォルトエンコーディングがUTF-8でないことは、多くのWindowsユーザー、特にプログラミング初心者にとって障害になっています。 UnicodeDecodeError で検索すると、多くのWindowsユーザーが問題に遭遇しているのがわかります。 https://qiita.com/Yuu94/items/9ffdfcb2c26d6b33792e https://www.mikan-partners.com/archives/3212 https://teratail.com/questions/268749 https://github.com/neovim/pynvim/issues/443 https://www.coder.work/article/1284080 https://teratail.com/questions/2713
Googleが開発したSwisstableと呼ばれるハッシュテーブル実装がAbseilとして公開されて、Rustの標準のHashMap実装にもその移植であるhashbrownが採用されました。 Swisstable の面白いところは、8または16要素をグループ化して、グループ内の各要素のハッシュ値のうち7bitをそれぞれ1byteに格納した8または16バイトの配列を作り、その配列に対して一気に並列でマッチングを行うことです。 この並列マッチングにはSSE2もしくはビット演算が使われます。この記事ではこの並列マッチング部分について解説します。 SSE2を使う場合 SSE2を使う場合は、グループのサイズは16になります。ハッシュ値を格納する配列のことを control と呼ぶことにすると、 control は char control[16] になります。control の各バイトの状態は次の
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を
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でハッシュ値をキャッシュしているためにそこまで大きなインパクトがなかったこともあり、ずっと放置されてい
訂正 昔から deprecate されているのにずっと生き残ってるヤツたちはクセモノのぞろいで、全然初心者向けではありませんでした。 代わりに、Docディレクトリを deprecated-removed:: で grep して、 3.10 で削除する予定になっているものを削除する方がずっと楽なので、そちらに挑戦してみてください。削除する手順は下の記事のままで大丈夫です。 Python 3.9 がベータに入り、masterブランチはPython 3.10の開発に入りました。 はっきりとした区分はないものの、Python 2.7との互換性のために長くdeprecated状態を維持していたメソッドの削除に踏み切るバージョンになりそうです。そこでこんなIssueを作ってみました。 Issue 41165: [Python 3.10] Remove APIs deprecated since Pyt
go-sql-driver/mysql のバッファサイズが4KiBなのは小さすぎる？？ - methaneのブログ
qiita.com そもそも fetchall があればパフォーマンスが上がるわけでは無いので。https://t.co/O4u3zZcnYx これを16KiBにしたらパフォーマンス上がるはず。— Inada Naoki (@methane) December 17, 2020 go-sql-driver/mysql のバッファサイズは4KiBで、大きいクエリを送るなり大きいパケットを受信すれば自動的に増えますが、小さいrowを大量に受信する場合は4KiBのバッファを使って何度もReadをしてしまいます。これを大きくすればReadの回数が減って高速化できそうな気がします。 ということで、話題のリポジトリをforkして、DBからselectしてCSVを書き出す部分だけを100回ループしてみました。CSVの書き出しがネックにならないようにbufio.NewWriterSize()を使ってバッフ
methane.hatenablog.jp この記事で紹介した、 open() などでエンコーディングを指定せずに暗黙でデフォルトのエンコーディングが使われた時に EncodingWarning を発生させる機能のPEPが受理され、実装し、昨晩リリースされた Python 3.10a7 に入りました。 .bashrc などで extern PYTHONDEFAULTENCODING=1 などとしておけば、デフォルトエンコーディングを使用している箇所に警告が表示されます。自分で書いているプログラムだけでなく、利用しているツールやライブラリ、フレームワークに対する警告についても見かけたら開発元に報告してもらえると助かります。 警告を見つけた場合にどうするべきか、簡単に説明します。 UTF-8を利用している場合 MarkdownやYAML、TOML、JSONを開くのに encoding 引数を指
この記事は KLab 2020 Advent Calendar の 12/2 分になります。 qiita.com 最近の Python に対する改善を紹介します。私が設計、コードレビューまでしましたが、実装は他のコントリビューターにしていただきました。 (プルリクエストはこちら) 背景として、Python 3.10 からは from __future__ import annotations がデフォルト化され、アノテーション部分は実行時に評価されずにただの文字列になります。( PEP 563 を参照してください。) >>> def add(a: int, b: int) -> int: ... return a+b ... >>> add.__annotations__ {'a': 'int', 'b': 'int', 'return': 'int'} アノテーションが実行時に評価されな
Pythonのdictのサイズをよりコンパクトにする改善をしました。今日リリースされたPython 3.11.0a6に含まれています。 bpo-46845: Reduce dict size when all keys are Unicode. by methane · Pull Request #31564 · python/cpython · GitHub Pythonのdictで一番メモリを使っているのはエントリーの配列です。エントリーは次のような構造体です。 typedef struct { /* Cached hash code of me_key. */ Py_hash_t me_hash; PyObject *me_key; PyObject *me_value; /* This field is only meaningful for combined tables */
Go 1.22 のリリースが近づいていますが、その中でdatabase/sqlにNull[T]を追加したので紹介しておきます。 database/sql パッケージにはNullByte,NullBool,NullFloat64,NullInt64などのNullableなカラムを扱うための型が用意されているのですが、NullUInt64はありませんでした。 UInt型が標準的ではなく、driver.Valueにもuint64が含まれていないからです。 一方でMySQLはunsigned tinyint~bigint型があるのでgo-mysql-driverもuint64には対応しています。32bitまではint64で、64bitではuint64で扱うようになっています。 だからと言ってドライバー独自に NullUInt64 を提供すると、他のパッケージも同じ型を提供した時に混乱の元です。 と
![sql.Null[T] をGo 1.22に追加しました - methaneのブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/4434e16c846cfb04c4f800f55e0551ebaa75c9b7/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929890341541%2F6801883189077976653%2F1706778658)
go-mysql-driverに来たバグ報告を調べていたら、 database/sql.RawBytes の利用方法にハマるとデバッグの難しい落とし穴があったのを見つけたので、Go側のバグとは断言できないもののGo側で直すべきだと報告しました。他の人がハマらないように簡単に解説しておきます。 github.com RawBytesはtype RawBytes []byteのように宣言されていて、[]byteのように扱える。[]byteとの違いは、利用可能期間が短くてrows.Scan(&in)からrows.Next()かrows.Close()までの間にしか使えないという制約があることだ。 rows.Next()が呼ばれた時、ドライバーは受信バッファの中の文字列等のデータを浅い(shallow)コピーで返すことができる。そのデータは次にrows.Scan()が呼ばれた時に使われるのだが、S
オブザーバビリティ・エンジニアリング 作者:Charity Majors,Liz Fong-Jones,George Mirandaオーム社Amazon オブザーバビリティ・エンジニアリングの5章のタイトルは「構造化イベントはオブザーバビリティの構成要素である」です。構造化イベントの定義は5.1節にあります。 イベント とは、本番環境のサービスへの影響を理解するために、ある特定のリクエストがそのサービスとやりとりしている間に発生したすべての記録です。 そこからさらにイベントの記録について説明が続きます。 空のマップを初期化することから始めます。このマップには、そのリクエストの有効期間中に発生したものに関する興味深い詳細、 たとえばユニークID、変数の値、ヘッダー、リクエストで渡されたすべてのパラメーター、実行時間、リモートサービスへのコール、それらのリモートコールの実行時間など、後にデバッ
ずっと前から deprecated になっていた easy_install コマンドが、setuptools53でとうとう消えました。 今後リリースされる Python にはこのバージョン以降の setuptools がバンドルされ、Python をインストールした時に bin/ ディレクトリに入るゴミが1つ減るはずです。 めでたしめでたし。
年末年始はこの本を読んでいた。 GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ 作者:千田 和央翔泳社Amazon コピーコントロールがない電子書籍が買える場合はなるべくKindleよりもそちらを買うことにしている。 翔泳社は自前でPDF版を売っていて、しかもしばしば40%オフといった大幅値引きのセールを行なっているので、今回はそこで買った。 www.seshop.com オライリーや技術評論社の電子書籍はePubが取得できる場合が多くて、基本はGoogle Play Booksのアップロード機能を使い、Kindleでも読める本の場合はSend to Kindleを使っている。 しかしKindleやGoogle Play Booksは、PDFの目次が表示できないので使いづらい。Acrobatか、iPadで
Mailman 3 [python-committers] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642 - python-committers - python.org パターンマッチング構文が複数提案されていたのですが、 PEP 634, 635, 636 が Accept されました。順調にいけば今年リリース予定のPython 3.10に搭載されるでしょう。 大きい提案なのでPEPが3つに分けられています。 PEP 634 -- 仕様 PEP 635 -- 追加する理由 PEP 636 -- チュートリアル 興味がある人はチュートリアルだけ読めば使い方がわかるようになっています。
* You shouldn't use the issue tracker to ask about the error you saw. **OSS maintainers are not free tech support!!** People like you are killing OSS which maintained by volunteers. Read [this article](https://medium.com/@methane/why-you-must-not-ask-ques
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
`from __future__ import annotations` がPython 3.10でデフォルトにならなくなりました - methaneのブログ
PEP 563 は Python 3.10 でデフォルトになる予定で、実際に去年の10月から master ブランチでは有効になっていました。今までの Python 3.10 のアルファ版でも有効になっています。 www.python.org このPEPはアノテーションの実行時の利用に後方非互換性と大幅な制限を加えてしまいます。 >>> class C: ... a: int ... >>> C.__annotations__ {'a': <class 'int'>} この例では __annotations__ に int クラスのオブジェクトそのものが入っていますが、PEP 563が有効になると "int" という文字列が入るので、直接 __annotations__ を見ていたコードは動かなくなります。 PEP 563 が有効でなくてもPEP 484に従ったtype annotatio
PEP 723がAcceptされて、pipx runで依存ライブラリがあるスクリプトを実行できるようになっていた - methaneのブログ
時間がなくて議論を追っていなかったのですが、標準ライブラリ以外に依存したスクリプトを手軽に配布・実行するための提案である PEP 722 と PEP 723 がしばらく前から議論されていて、先月にPEP 723の方がAcceptされていました。 PEPのサンプルを引用しておきます。 /// script と /// で囲われている部分に、必要とするPythonのバージョンと、依存するライブラリを書いています。 # /// script # requires-python = ">=3.11" # dependencies = [ # "requests<3", # "rich", # ] # /// import requests from rich.pretty import pprint resp = requests.get("https://peps.python.org/api/
みんなtai64nを使おう。と言いたいところだけれど、サポートしてるところが見当たらないのでナシだ。 個人的に好きなのはナノ秒単位のUnixタイムスタンプだ。 OpenTelemetryのOTLPでもナノ秒タイムスタンプを使っている。 "logRecords": [ { "timeUnixNano": "1544712660300000000", (opentelemetry-protoのexample より) しかし、これはスキーマが厳密に定義されているOTLPだからこそできる事であって、普通にJSON linesのログをあちこちで扱うには問題がある。 レコード名が "time" や "timestamp" だとナノ秒なのかマイクロ秒なのかわかりにくい そもそも人間はUnixタイムスタンプを読めるようにできていない 整数の代わりに実数を使えば、精度はマイクロ秒に落ちてしまうものの、単位が
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
バグがあっても接触確認アプリをインストールしてほしい理由 - methaneのブログ
pyenvを初心者に薦めるのはもうやめよう - methaneのブログ
構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
PEP 8騒動について - methaneのブログ
Python 3.12 から Unicode のサイズが小さくなります - methaneのブログ
PythonのマルチスレッドWSGIサーバーの選定 - methaneのブログ
PythonのデフォルトエンコーディングをUTF-8にするために - methaneのブログ
Swisstable Hash に使われているビット演算の魔術 - methaneのブログ
Python 3.10 の開発（お掃除）に参加しよう - methaneのブログ
PYTHONWARNDEFAULTENCODINGを使おう - methaneのブログ
関数アノテーションを軽量化しました - methaneのブログ
Python 3.11のdictのメモリ消費削減 - methaneのブログ
sql.Null[T] をGo 1.22に追加しました - methaneのブログ
RawBytesは使い捨てよう - methaneのブログ
構造化ログから構造化イベントへ - methaneのブログ
easy_install が消えた - methaneのブログ
PDFをタブレットで読む - methaneのブログ
パターンマッチングがAcceptされました - methaneのブログ
構造化ログのタイムスタンプ形式 - methaneのブログ
forbesjapan.com
x.com
note.com/tomokiuchino
www.yomiuri.co.jp
b.hatena.ne.jp
www.chikanonbe.com