幹壞事是進步最大的原動力
在「Show HN: Httpdbg – A tool to trace the HTTP requests sent by your Python code (github.com/cle-b)」這邊看到的，看起來是作者自己貼到 Hacker News 上的。
作者開發了 httpdbg 套件，可以看 Python 程式有哪些 HTTP(S) 連線，看起來對於開發追蹤還蠻好用的。
從官網可以看到支援了常見的 HTTP(S) library，包括常用的 requests 以及其他套件。
不過特地想提的是看到 urllib3 這個套件，第一次看到這個東西... 這名字看起來就跟以前 Python 2 年代時搞出來的 urllib 以及 urllib2 有關？
在「Free-threaded CPython is ready to experiment with (quansight.org)」這邊看到 Python 拔 GIL 的進度，從原文「Free-threaded CPython is ready to experiment with!」這邊可以看到有些需要套件一起配合的，像是 NumPy 這邊的「BUG: error Python 3.13 free-threaded RuntimeError: Identity cache already includes the item.」。
看起來用到 C 的實作 (大多數應該是為了加速，或是需要底層的 syscall) 都會需要注意一下。
另外值得一提的是目前拔掉 GIL 的版本在 single threading 的情況下會比標準版的 Python 3 慢很多，會需要後續再改進，所以一開始的版本就算穩定下來也可能沒有經濟上的效益，參考 id=40949628 這邊提到的：
Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. Part of what my colleague Ken Jin and others are working on is getting back some of that lost performance by applying some optimizations. Expect single-threaded performance to improve for Python 3.14 next year.
另外有看到一些有趣的討論，像是為什麼不 bump 版本號碼到 Python 4 (因為語法沒有大改變？)。
Python 2 在大約四年前 2020/04/18 推出了最後一版 Python 2.7.18 後，後續的安全性更新就變成要找第三方支援了。
在 2023/09 出的 Trac 1.6 總算是換到 Python 3 後，手上就沒有遇到要用 Python 2.7 的東西了...
剛剛在「PyPy v7.3.16: release of python 2.7, 3.9, and 3.10」這邊看到跟 Python 2.7 有關的消息，一時興起翻了翻有哪些延長的商業支援可以買，看起來有兩個：
真的遇到的話再來寫信問問看好了...
Cloudflare 宣佈 Cloudflare Workers 支援 Python：「Bringing Python to Workers using Pyodide and WebAssembly」。
不過比較特別的是，並不是原生支援 Python 環境，而是透過轉譯成 WebAssembly 丟進 V8 engine 執行，就如同文章標題提到的。
另外是套件的部分，照這個文字的說明，應該不是所有的套件都可以丟進去用 (can import a subnet of popular Python packages)，支援的套件看起來是預先 compile 好：
All bindings, including bindings to Vectorize, Workers AI, R2, Durable Objects, and more are supported on day one. Python Workers can import a subset of popular Python packages including FastAPI, Langchain, Numpy and more. There are no extra build steps or external toolchains.
看起來是打算全部都用 javascript 當作基礎？
Hacker News 上看到「gh-116167: Allow disabling the GIL (github.com/python)」這個討論，原連結在「gh-116167: Allow disabling the GIL with PYTHON_GIL=0 or -X gil=0 #116338」這邊。
可以看到 Python 提供透過環境變數拿掉 GIL 的方式，讓大家可以更方便測試。
要注意的是這就只是「拿掉 GIL」，沒有說東西會正常 (噗)：
Trying to run the full test suite crashes pretty quickly, in test_asyncio.
但這讓其他人可以更方便測試，算是很不錯的進展...
社群好幾個地方都有提到的「uv: Python packaging in Rust」這個，文章開頭的說明有快速說明目標是 pip 的 drop-in replacement：
TL;DR: uv is an extremely fast Python package installer and resolver, written in Rust, and designed as a drop-in replacement for pip and pip-tools workflows.
這跟「Ruff：用 Rust 寫的 Python Linter」都是 Astral 下的專案，主打用 Rust 改善速度的專案。
馬上想到的是 package resolver，這指的是依照每個套件指定的相依條件，找出符合所有條件的版本組合。
這在各個語言的套件系統上都是痛點，而在「Dependency hell is NP-complete」這篇就有指出這是 NP-complete。
這是因為 3SAT 問題可以 PTIME 轉成 package resolver 問題 (於是就 NP-hard 了)，再加上有 PTIME 的驗證，就變成 NP-complete 了。
但看說明應該是不只這個部分，包括了一些 i/o 類操作的改善。
除了速度以外，uv 也提供了讓測試更方便的功能，像是在計算相容版本時，預設的演算法是儘量都裝最新版，但你可以指定要儘量裝最舊的版本，這樣對於相容性測試頗有用的：
But by passing
--resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)
這個工具的出現也是頗有幫助，我記得寫 Python 專案時隨便引入個 Django，再多拉幾個套件，跑起 package resolver 就要花不少時間了，可以想像中大型專案在這塊的痛點...
另外剛剛回去看了 ruff，從去年四月 500+ 條規則增加到 700+ 條了，在發表受到注目後應該補了不少社群常用到的規則，說不定新專案可以無痛跳進去了，去年的時候試著用，有發現常見的規則還沒有支援...
Django 5.0 的消息出來了：「Django 5.0 released」，比較完整的 release notes 則是在這邊：「Django 5.0 release notes」。
對應的 Django 4.2 因為是 LTS，會支援到 2026/04：
With the release of Django 5.0, Django 4.2 has reached the end of mainstream support. The final minor bug fix release, 4.2.8, was issued today. Django 4.2 is an LTS release and will receive security and data loss fixes until April 2026. All users are encouraged to upgrade before then to continue receiving fixes for security issues.
Django 5.0 比較大的 incompatibility 會是 Python 版本的要求：
Django 5.0 supports Python 3.10, 3.11, and 3.12. We highly recommend and only officially support the latest release of each series.
The Django 4.2.x series is the last to support Python 3.8 and 3.9.
關於 Python 版本的部分，交叉參考「Status of Python versions」這邊的說明，可以看到目前還在提供安全性更新 (狀態是 security) 的 3.8 (到 2024/10) 與 3.9 (到 2025/10) 在 Django 5.0 被放掉了...
現在 Django 的大版號更新比較像是常態性把有破壞相容性的更新整理起來出新版，倒不是動到什麼大結構...
前幾天 Hacker News 上討論到的一篇：「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」，原文則是在「Rust std fs slower than Python!? No, it's hardware!」。
原因是作者收到回報，提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal()，透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal()，直接用 Python 的 open() 開然後讀取)。
先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。
FSRM 類的指令被用在 memcpy() 與 memmove() 類的地方，算是很常見備用到的功能，這次追蹤的問題發現在 glibc 裡面用到導致效能異常。
另外也可以查到在 Linux kernel 裡面也有用到：「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」，所以後續應該也會有些改善的討論...
在 Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這，上游的 glibc 也有對應的追蹤：「30995 – Zen 4: sub-optimal memcpy on very large copies」。
從作者私下得知的消息，因為 patch space 的大小限制，AMD 可能無法提供 CPU microcode 上的 patch，直接解決問題：
However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.
所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround，回到原來沒有 FSRM 的方式處理：
Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.
另外在追蹤問題的過程遇到不同的情境，得拿出不同的 profiling 工具出來用，所以也還蠻值得看過一次有個印象：
一開始的 timeit 算是 Python 裡面簡單的 benchmark library：
接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑)，查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+)：
再來是用 strace 追問題，這個算是經典工具了，可以拿來看 syscall 被呼叫的時間點：
到後面出現了 perf 可以拿來看更底層的資訊，像是 CPU 內 cache 的情況：
接續提到的「hotspot ASM」應該也還是 perf 輸出的格式，不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析：
而文章裡的則是可以看到已經到 assembly 層級了：
差不多就這些...
在 Simon Willison 這邊看到「It's Time For A Change: datetime.utcnow() Is Now Deprecated」，引用的文章是「It's Time For A Change: datetime.utcnow() Is Now Deprecated」這篇。
文章裡面有提到歷史因素，以及這樣設計造成的問題。
在文章後面有提到替代方案，改了一下裡面的用法，等價於這個：
from datetime import datetime, timezone datetime.now(timezone.utc) datetime.fromtimestamp(timestamp, timezone.utc)
或是這樣：
import datetime datetime.datetime.now(datetime.timezone.utc) datetime.datetime.fromtimestamp(timestamp, datetime.timezone.utc)
要稍微注意一下這個歷史遺跡要被拆了... (StackOverflow 上面應該有很多用到這兩個 function 的解答)
續上篇「修好 Trac 1.6 上的 TracSubtickets」提到的，反正 Trac 這個 community 的東西如果爛掉的話，自己修會比較快...
SlackIntegration 從字面上的意思就知道，是把 Trac 這邊的更新同步到 Slack 上的工具。
這包主要的問題是 Python 2 語法，所以在修的過程中間就不斷的在想起「啊，這是當初 Python 3 的 break-BC 改動」。
從「Comparing 72bec82..master · gslin/trac-slack-plugin」這邊可以可以到修正的東西，主要修正的都是跟 unicode 有關的程式碼。
一塊是 2to3 修正的，把 u'...' 這種字串直接變成 '...'，不需要額外指定，另外是 unicode(...) 變成 str(...)。
另外一個也還是 unicode 相關的，但因為是邏輯上的部分，2to3 沒有抓出來的，是 encode('utf-8') 的部分看起來就用不到了，這在 Python 3 裡面 requests 會自動處理掉，只要丟標準的 string (unicode string) 進去就可以了。
這樣又弄好一個套件了...