pipのキャッシュの管理 - methaneのブログ
MySQL 8.4がリリースされて、定番の「mysqlclient をインストールしたんだけど動かない」という報告が来た。これはpipが以前にビルドしたバイナリをキャッシュして再利用しているためで、前のバージョンのlibmysqlclientにリンクしたバイナリなのでバージョンアップしたら当然動かなくなる。 この解決方法と合わせて、pipのキャッシュについて簡単に説明していこうと思う。 pip.pypa.io 2種類のキャッシュ pipのキャッシュには2種類ある。HTTPレスポンスを保存するHTTPキャッシュと、ソースパッケージをビルドした結果を保存するwheelキャッシュだ。 wheelが提供されていたらHTTPキャッシュのみが使われる。wheelキャッシュはソースパッケージからインストールするときしか使われない。 最近はpure PythonパッケージでもWheelを提供することが増え
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
Python 3.11のdictのメモリ消費削減 - methaneのブログ
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 */
`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
PYTHONWARNDEFAULTENCODINGを使おう - methaneのブログ
methane.hatenablog.jp この記事で紹介した、 open() などでエンコーディングを指定せずに暗黙でデフォルトのエンコーディングが使われた時に EncodingWarning を発生させる機能のPEPが受理され、実装し、昨晩リリースされた Python 3.10a7 に入りました。 .bashrc などで extern PYTHONDEFAULTENCODING=1 などとしておけば、デフォルトエンコーディングを使用している箇所に警告が表示されます。自分で書いているプログラムだけでなく、利用しているツールやライブラリ、フレームワークに対する警告についても見かけたら開発元に報告してもらえると助かります。 警告を見つけた場合にどうするべきか、簡単に説明します。 UTF-8を利用している場合 MarkdownやYAML、TOML、JSONを開くのに encoding 引数を指
関数アノテーションを軽量化しました - methaneのブログ
この記事は 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'} アノテーションが実行時に評価されな
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 というすご
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は特に今で言うマイクロサービス的なものを（色んな意味で）効率よく開発するため
Windows では2020年を待たずに Python 2.7 が使い物にならなくなっていく - methaneのブログ
昨日 mysqlclient 1.3.10 をリリースしました。 今までは Windows 版の wheel は Python 2.7 だけに提供していたのですが、 1.3.10 からは 3.5 と 3.6 だけに提供して 2.7 はドロップしました。 そもそも今まで Python 3 に wheel を提供できてなかったのは、 MySQL Connector/C の VC14 (VS2015) に対応したライブラリが提供されておらず、 Python 3.5, 3.6 は VC14 でビルドされていて VC12 用のライブラリにリンクすると大量のエラーでるわ自分で手順読みながら頑張って MySQL をソースからビルドしてもなんか動かないわで諦めてたからです。 それが、2年待て、よーーーやく MySQL Connector/C 6.1.9 から VC14 のライブラリが同梱される用になりまし
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 がより完成
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 を採用
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チューニングの基本は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代
logger のパフォーマンスについて [Go] - methaneのブログ
Go の logging ライブラリ、今はとりあえず標準ライブラリの log か google/glog を使っているんだけど、 log は機能不足が、 glog は Google 標準ライブラリなのでフォーマットを調整したり flag 以外でカスタマイズするために fork しないといけなかったりするので、他のロギングライブラリどれが良いか時々話題の logger を覗いてみていた。 結果、もう logrus で良いかなーと思っているんだけどそれはいったん置いておいて、選定基準の1つのパフォーマンスについて書いておく。 logger のパフォーマンスで一番重要なのは、ログを書かない時のパフォーマンスだ。 デバッグ用の詳細なログをいたるところに散りばめているアプリケーションでも、ログレベルを WARN にしておけば、 DEBUG レベルのログがパフォーマンスに与える影響を最低限にできるべき
![logger のパフォーマンスについて [Go] - methaneのブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ad5a2040f52b4361f9d607306530d27f1616eb6f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929890341541%2F6653458415121150329%2F1442478380)
Python の新しいプロファイラ vmprof が面白い - methaneのブログ
PyPy 2.6 と同時に、 vmprof という CPython/PyPy 用のプロファイラが登場しました。 私はまだ PyPy では使っていませんが、CPythonのプロジェクトをこれでプロファイル取ってみたらなかなか面白かったので紹介します。 概要 Python にはもともと標準ライブラリとしてプロファイラ (cProfile) が付いてきていますが、これは関数の呼び出しと戻りでコールバック関数を呼び出しつつ実行時間を計測するタイプのプロファイラで、短時間でも正確なプロファイルが取れる反面、オーバーヘッドが大きく、小さい関数をたくさん呼び出す部分がオーバーヘッドでより大きく見えてしまうなどの問題がありました。 これと別の種類のプロファイラとして、定期的にサンプリングして、サンプルが多いところが実行時間も多いハズ、というプロファイラもあります。こちらはある程度の量のサンプルを集めないと
%25E3%2581%2595%25E3%2582%2593%25E3%2581%258C%25E5%258F%2582%25E5%258A%25A0%25E3%2581%2597%25E3%2581%25BE)
PyMySQLのメンテナにSQLAlchmey開発者のMike Bayer (@zzzeek)さんが参加しました - methaneのブログ
このブログでも数回紹介していたとおり、今メジャーな Python の MySQL ドライバ3つのうち2つ (MySQL-python の fork の mysqlclient と PyMySQL) を僕がほぼ単独でメンテナンスしている状況でした。 メンテナンスしているといっても、両方とも MySQL-python との互換性を第一に掲げているので、 Python 3 対応が終わった後はほとんど進化は無くて、淡々とバグの修正を積み重ねては1年に1度以上リリースするという程度です。 実際には Python では PostgreSQL 周りに比べて MySQL 周りは遅れていて幾つか改善案はあったのですが、子育てや他にも Python でやりたい事があったり仕事でも Go で楽しんでたりして手を付けられていませんでした。 そんな状況の中、 Mike さんが PyMySQL-Users ML に突
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 のサポートを切れる時期なので、思い当たる人は目を通してお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
easy_install が消えた - methaneのブログ
