requestsで長時間Sessionを使う場合はidle_timeoutに注意 - methaneのブログ
Pythonで一番人気のあるHTTPクライアントライブラリはrequestsですが、requestsやその低レイヤーであるurllib3はidle_timeoutの設定を持っていないので、長時間アイドルが続いた接続を再利用した時に Connection Reset by Peer エラーが発生することがあります。 このエラーを避けるためにurllib3はリクエストを送信する前に0バイトのreadを行って接続が生きているか確認しているのですが、サーバー側が接続を切断するのと同時にリクエストを送信してしまう場合にはその確認をすり抜けるので、ごく低頻度にエラーが起こってしまいます。 意図的にこのエラーを再現させてみます。Goを使ってidle_timeoutが1秒のサーバーを作ります。 package main import ( "net/http" "time" "fmt" "log" ) fu
Python 3.14の新機能：asyncioタスク可視化機能を使ってみよう | gihyo.jp
Python Monthly Topics Python 3.14の新機能：asyncioタスク可視化機能を使ってみよう 福田（@JunyaFff）です。2025年9月の「Python Monthly Topics」では、Python 3.14で追加されるasyncioタスク可視化機能であるasyncio psコマンド、asyncio pstreeコマンドと、asyncio.print_call_graph()関数、asyncio.capture_call_graph()関数を紹介します。 はじめに さまざまな機能強化が予定されているPython 3.14の中で、今回筆者が注目するのはasyncioの新しい可視化ツールです。asyncio psコマンド、asyncio pstreeコマンドと、asyncio.print_call_graph()関数やasyncio.capture_ca
httpxのパフォーマンス問題について - methaneのブログ
前回の記事でhttpxの検討を進めた後にこんな気になる記事を見かけたので現状を調査しました。 gfx.hatenablog.com 結論から言うと、これは httpx を async で利用する時の問題で、現状ではまだ解決されていません。同期APIを使っていれば問題ありません。 原因は、httpxの低レイヤーライブラリであるhttpcoreがanyio.Lockを使っていたのですが、その実装がasyncio.Lockよりも大幅に遅いことです。httpcoreに提案されている解決策は3つあります。 anyio依存排除 https://github.com/encode/httpcore/pull/922 anyioに追加された fast_acquire を利用する https://github.com/encode/httpcore/pull/953 コネクションプールの実装見直し http
PrefectではじめるPythonワークフロー・フレームワーク | gihyo.jp
門脇（@satoru_kadowaki）です。2025年8月の「Python Monthly Topics」は、データパイプラインやワークフロー、ETLで利用されるワークフロー・フレームワーク[1]「Prefect」について紹介します。 ワークフロー・フレームワークとは何か データを扱う現場では、定期的に実行する処理が必ず存在します。たとえば、指定した時間やタイミングでデータを集計したり、データがアップロードされたら自動でデータベースに反映したりするなど、一定のルールに基づいて処理を行うことがよくあります。 こうした処理は、最初はローカルでのスクリプト実行やLinuxであればCronジョブで十分に運用できます。また、AWSなどのクラウド基盤を利用している人は、Lambdaのようなイベント駆動による実行環境を作成して運用する事例も多いのではないかと思います。 しかし、シンプルな処理ではそれ
OptunaにおけるPython free threading (v3.13t)対応状況について - Preferred Networks Research & Development
本記事はアルバイトとして勤務されている加藤大地さんによる寄稿です。 はじめに Python 3.13 より、PEP 703 で提案された free threading が実験的にサポートされるようになりました。これまで、Python（厳密にはCPython）のインタプリタでは、global interpreter lock (GIL) という機構によって、同時刻において1つのスレッドしか実行できないようになっており、これによってスレッドセーフであることを保証していました。しかし、3.13 で導入された free threading により、複数のスレッドが同時に実行できるようになったことで、実行時間の短縮が見込まれます。 その一方、C-APIにいくつかの後方互換性のない変更が加わったことで、一部のC拡張モジュールがfree threading モードでは正しく動作しなくなる可能性があり、p
zipapp — Manage executable Python zip archives
Command-Line Interface¶ When called as a program from the command line, the following form is used: If source is a directory, this will create an archive from the contents of source. If source is a file, it should be an archive, and it will be copied to the target archive (or the contents of its shebang line will be displayed if the –info option is specified). The following options are understood:
Excel上でWebAssembly版Pythonを実行可能にするアドオン「Anaconda Code」が登場
Python関連のツールベンダとして知られるAnacondaは、Excel上で直接Pythonコードを実行できる新機能「Anaconda Code」を含むExcelのアドオンツール「Anaconda Toolbox in Excel」をパブリックベータとして公開しました。 You can now run Python directly in Excel locally w/ the new Anaconda Code add-in! Public beta is live! Faster performance, flexible data handling, editable initialization, & customizable environments. Read more in our blog & follow @anacondainc: https://t.co/9LAy
Ryeに見る自己完結型Pythonとライセンスの話 - techtekt
目次 目次 はじめに 検証環境 pyenv + Poetryのインストールとプロジェクト作成 pyenvのインストール Poetryのインストール プロジェクト作成 Ryeのインストールとプロジェクト作成 インストール プロジェクト作成 pyenv環境とRye環境のPythonの挙動の違い readlineモジュール なぜRyeのPythonはlibeditを使用するのか pyenvよるPythonのインストール RyeによるPythonのインストール ライセンスの問題 ユーザへの影響 まとめ はじめに Pythonの開発において、pyenvによるバージョンの切り替えと、Poetryによるプロジェクト管理の組み合わせを使用されている方は多いかと思います。 そんな中、ワンストップなプロジェクト・パッケージ管理ツールとして近年登場し、話題となっているのがRyeです。 rye-up.com Ry
Python 3.12で増えた並列処理と、これまでの並列処理の挙動を比べてみる - Qiita
この記事ですることを3行で Pythonの標準ライブラリでできる並列実行を、あらためて総当たりで速度比較しよう ウォーターフォールチャートで、それぞれの並列処理の処理時間の特徴を可視化しよう boto3の実行をモデルケースにして、どの並列処理が一番早いのかを調べよう この記事の結論を先に Python 3.12から本格的に使えるようになったサブインタープリターは、CPUで実行する処理について言えば、従来のサブプロセスよりも高速 boto3の実行は、サブインタープリターよりも署名付きURLの非同期実行のほうが速い → S3からの10ファイルの取得であれば、実行時間を90%削減できます → Bedrockの3回実行であれば、実行時間を60%削減できます 今回使ったソースコードはこちらに置いています。 お手持ちの環境で再実行できるようにしていますので、気になる方はぜひ。 どうしてこの記事を書くの
uWSGIで大きいログが壊れないようにする設定 - methaneのブログ
uWSGIがファイルやパイプにログを書くときは、各ワーカープロセスが直接ファイルやパイプに書く場合と、一旦masterプロセスにログを送ってmasterプロセスからログを書く場合があります。 masterプロセスにログを送る設定は --log-master ですが、このオプションを暗黙的に有効にするオプションがあります。 UWSGI_OPT_LOG_MASTER か UWSGI_OPT_REQ_LOG_MASTER というフラグが指定された場合に log_master が設定されるようになっていて、uwsgi-2.0ブランチではこれらのオプション（エイリアスを含む）にそのフラグが指定されています。 touch-logrotate touch-logreopen log-syslog log-socket req-logger logger-req logger threaded-logge
PythonのマルチスレッドWSGIサーバーの選定 - methaneのブログ
今までuWSGIをシングルスレッド、マルチプロセスで使っていたのだけれども、昔に比べて外部のAPI呼び出しが増えているのでマルチスレッド化を検討している。 uWSGI uWSGIでマルチスレッドを有効にした時は、各workerスレッドがacceptする形で動作する。スレッド数以上の接続をacceptすることがないので安心。 プロセス内のスレッド間ではmutexで排他されて、同時にacceptを実行するのは1スレッドのみに制限されている。つまりthendering herd問題はプロセス間でしか起こらない。マルチスレッド化でプロセス数はむしろCPUコア数まで減らせるので、thendering herd問題はむしろ今よりも軽減できる。（ちなみにプロセス間でもロックしてthendering herdを許さないオプションもあるけど、プロセス間同期は怖いので使っていなかった。） ただしuWSGIのマ
pypackaging-native
Home Home Meta topics Key issues Other issues Background References Glossary Home Introduction Packaging is an important and time-consuming part of authoring and maintaining Python packages. This is particularly true for projects that are not pure Python but contain code that needs to be compiled, and have to deal with distributing compiled extensions and with build dependencies. Many projects in
PEP 703 - 兼雑記
https://peps.python.org/pep-0703/ Python の GIL 外す話。これすごく楽しい読みものでした。参照カウントのところが一番人気だと思うのですが、他のところも色々良い。こういう、「んーこういうことするとこういう問題が起きない？」と思ったら次の章くらいでそれが説明される、みたいな読みものは大変好きです 参照カウント: オブジェクトっていうのは作ったスレッドが解放するというのがほとんどなんだから、その場合はロックをいらなくする、他に渡ったら普通の参照カウントぽくする、という話。 Swift に 2018 年に導入された 話らしい。他のスレッドに渡された後で DECREF すると他スレッド用の参照カウントが負になりうるのだけど、その時に queue に入れるということをして、ややこしいので、なんかこれ無しですむ方法はないのかなぁ……と Immortalize
Debugging a Mixed Python and C Language Stack | NVIDIA Technical Blog
Debugging is difficult. Debugging across multiple languages is especially challenging, and debugging across devices often requires a team with varying skill sets and expertise to reveal the underlying problem. Yet projects often require using multiple languages, to ensure high performance where necessary, a user-friendly experience, and compatibility where possible. Unfortunately, there is no sing
Welcome to Bandit — Bandit documentation
Welcome to Bandit Bandit is a tool designed to find common security issues in Python code. To do this, Bandit processes each file, builds an AST from it, and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files, it generates a report. Using and Extending Bandit
PyPIにおける潜在的な任意コード実行
はじめに(English version is also available.) PyPIは、セキュリティページ自体は公開しているものの、脆弱性診断行為に対する明確なポリシーを設けていません。1 本記事は、公開されている情報を元に脆弱性の存在を推測し、実際に検証することなく潜在的な脆弱性として報告した問題に関して説明したものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 PyPIに脆弱性を発見した場合は、Reporting a security issueページを参考に、[email protected]へ報告してください。 要約PyPIのソースコードを管理しているリポジトリのGitHub Actions上において、悪意あるプルリクエストが任意のコマンドを実行する事が可能な脆弱性が存在した。 これにより、当該のリポジトリに対して書き込み権限を得ることができ、結果
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - janbjorge/pgqueuer: PgQueuer is a Python library leveraging PostgreSQL for efficient job queuing.
GitHub - Textualize/textual: The lean application framework for Python. Build sophisticated user interfaces with a simple Python API. Run your apps in the terminal and a web browser.
GitHub - mckinsey/vizro: Vizro is a low-code toolkit for building high-quality data visualization apps.
Python Social Authで学ぶ、OAuth2.0認可コードフローにおける異常系への対処