Python 2.7 的延伸支援

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 Workers 支援 Python (是 open beta)

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 當作基礎?

透過環境變數拿掉 Python 的 GIL 限制 (目前會爛掉一堆東西)

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:用 Rust 寫的 Python Packaging 替代方案

社群好幾個地方都有提到的「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 的消息出來了:「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 的大版號更新比較像是常態性把有破壞相容性的更新整理起來出新版,倒不是動到什麼大結構...

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 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 層級了:

差不多就這些...

Python 3.12 將淘汰 datetime.datetime 的 utcnow() 與 utcfromtimestamp()

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 上的 SlackIntegration

續上篇「修好 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) 進去就可以了。

這樣又弄好一個套件了...

修好 Trac 1.6 上的 TracSubtickets

Trac 1.6 總算從死了三年的 Python 2.7 換成了 Python 3,所以算是蠻強大的升級動力,但也可以想像到相關的 plugin 其實因此爛了不少,加上 Trac 現再用的人愈來愈少,沒有人會修這些問題,所以你就得當「沒有人」跳下去修...

標題上提到的 TracSubtickets 算是這樣的一個套件,他的概念很好用,但大概從 Trac 1.2 以後就沒什麼更新了,先前有遇到 MySQL 8.0 的資料庫搭配起來會撞到關鍵字而出錯,得自己修。

而這次遇到的問題是 TracSubtickets 在頁面輸出子票資訊時用到 ITemplateStreamFilter 這個功能,而從官方文件開頭也可以看到問題:Trac 1.4 的時候內部的 template engine 就從自家研發的 Genshi 換成了 Python 社群用的更廣泛的 Jinja2,但當時只是先標成 deprecated,還沒到不能用,直到 Trac 1.5.1 時拔掉了,所以接下來的 Trac 1.6 就沒得用了。

在官方的「Replacing the ITemplateStreamFilter interface」有提出建議的方法,是用 JavaScript 改 DOM:

The only way left to alter the generated content is to perform these modifications dynamically on client-side using JavaScript.

我看了半天 Trac 1.6 的程式碼,看起來的確沒有什麼比較好的方法可以處理... 只能回來照官方的方法走,後續的問題就是看要處理的多乾淨 (或是多髒)。

因為 Trac 本身沒有 client template engine (像是 React 或是 Vue 之類的),我決定這邊還是讓 server 端全部把 html string 都產生出來,再由 client 端生一個 div 直接用 innerHTML 塞進去:這樣就不用傳一包 JSON 到 client 端慢慢組了...

於是就出現了這包 diff/patch:「Comparing cae40fb..master · gslin/trac-subtickets-plugin」。

基本的思路是,既然以前的 filter_stream() 是產生 html tree 的程式碼,那就重複拿來用,把結果輸出轉成 html string,用 add_script_data 丟到 window 下的 global variable (喔耶),再寫一段 javascript 把這串東西塞進本來在的 DOM 位置。

這樣至少就能動了...

Python 3 的支援週期

印象中之前有找過資料應該有寫過,但搜了一下沒翻到,可能是當初寫一寫刪掉了?

Python 的支援週期在「Status of Python versions」這頁可以看到,只看 Python 3 的部分的話,可以看出來從 3.2 之後的版本都是固定五年:

五年剛好與 UbuntuLTS 相同,好像有點微妙... 會遇到 Ubuntu 的 LTS 支援快要結束的時候,官方的支援也已經結束了,所以也的確有看到 18.04 (bionic) 後續的更新把 python3-minimal 升級到 3.8 版 (2019/10/14 出)。

看起來 20.04 (focal) 也會遇到類似的問題,目前的 python3-minimal 是 3.8.2-0ubuntu2,到 2024 年十月終止,而 20.04 (focal) 的 LTS 到 2025 年四月,應該也會生個版本?