離跟 GIL 說再見更進一步的 Free-threaded CPython

在「Free-threaded CPython is ready to experiment with (quansight.org)」這邊看到 PythonGIL 的進度,從原文「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 (因為語法沒有大改變?)。

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

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

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 年四月,應該也會生個版本?

Debian 移除 Python 2 套件

Hacker News 首頁上看到 Debian 移除 Python 2 的消息:「Python 2 removed from Debian (debian.org)」,對應的 ticket 在這邊:「#1027108 - RM: python2.7 -- RoQA; Obsolete - Debian Bug report logs」。

Python 2 從 2015 年喊 EoL 喊很久,終於在 2020/04/20 發行最後一版 Python 2.7.18

大多數的套件應該都有 Python 3 的支援了,有需要的人 (像是還是沒支援 Python 3 的 Trac) 可以透過 pyenv 建立 Python 2 的環境出來跑,或是丟進 Docker 裡面跑。

銀河的歷史又翻過了一頁...

Trac 開發版 1.5.1 對 Python 3 的說明

Trac 開發版 1.5.1 的 Change Log 裡可以看到說明:

This will be the only release in the 1.5.x release line that supports Python 2.7. Future releases will support Python 3.5+.

先前在 mailing list 上有看到 Python 3 的計畫,不過好像是第一次在 changelog 裡面看到說明了...

Python 2.7.18,官方提供的最後一個 2.7 的版本

本來 Python 2 官方的計畫是支援到 2020/01/01,但最後一個版本 Python 2.7.18 一直到剛剛 2020/04/20 才出。對照前一個版本 2.7.17,是 2019/10/19 的時候出的,這應該算是一個「經典」的落幕:「Python 2.7.18, the last release of Python 2」。

對於得用 Python 2 才能跑的專案 (目前手上應該就是 Trac),如果 Python 3 的版本再不出,再過個一年應該只能用 pyenv 撐場了...

用 Py-Spy 分析 Python 程式效率

這之後應該會變成 Python community 的神器之一...

剛剛看到分析 Python 程式效率的工具,只要有 pid 或是直接包著跑就可以分析:「Py-Spy: A sampling profiler for Python programs.」,執行起來長這樣:

而且還可以直接產生火焰圖讓開發者直接確認,超友善:

在 FAQ 的地方也有提到作者開發這套軟體的原因。有些在開發環境根本看不出問題的,可以很快的透過這個工具在 production 上看:

This project aims to let you profile and debug any running Python program, even if the program is serving production traffic.

另外一個重點在於其他常見的 profiling 工具通常都要改程式引用進來使用,這通常會使得程式效率慢下來,而 Pyflame 支援的平台比較少:

While there are many other python profiling projects, almost all of them require modifying the profiled program in some way. Usually, the profiling code runs inside of the target python process, which will slow down and change how the program operates. This means it's not generally safe to use these profilers for debugging issues in production services since they will usually have a noticeable impact on performance. The only other Python profiler that runs totally in a separate process is pyflame, which profiles remote python processes by using the ptrace system call. While pyflame is a great project, it doesn't support Python 3.7 yet and doesn't work on OSX or Windows.

Python 3 內建的 lru_cache...

Twitter 上看到 Python 3 內建的 lru_cache()

從文件上可以看到預設值是 128 個:

@functools.lru_cache(maxsize=128, typed=False)

tweet 裡面有討論到 memory leak 的問題可以看一下,不過如果是拿來寫工具的話,應該不會有什麼問題...

Python 3.7.0 以及效能

這幾天 Python 3.7.0 出了,這應該是 3.x 版第一個在一般性綜合測試有機會比 Python 2.7 快的版本。這邊拿二月時有人用 3.7 的 beta 版測試結果來看:「Which is the fastest version of Python?」。其中第一個圖就是 Djangodjango_html (render) 的測試,Y 軸是時間,所以是愈低愈好:

其他的幾張可以看到不是完全被 Python 2.7 抓著打了,算是出頭天了 (???),如果是用 pyenv 的人,把 pyenv 升級到新版後就可以安裝 3.7.0 了。

Google 弄出來的 Grumpy:把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy,可以把 Python 2.7 的程式碼轉成 Go:「Grumpy: Go running Python!」。

下面看到一個留言頗有趣的:

This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文,這次的需求主要是出自 YouTube 的需求:

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍:

除了 C extension 不支援外,還是有些「過於動態」的語法不支援:

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少,這個專案可以當作 YouTube 這種規模的網站所做的改善,而不是什麼可以拿來用的工具 :o