Tag: python

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 之後的版本都是固定五年：

五年剛好與 Ubuntu 的 LTS 相同，好像有點微妙... 會遇到 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 年四月，應該也會生個版本？

Python 內建的工具

在 Hacker News Daily 上看到「CLI tools hidden in the Python standard library」這個，在講 Python 內建的工具。

其中 python -m calendar 這組看起來還不錯，測了一下可以用 python -m calendar 2024 顯示所有 2024 的月曆，用 python -m calendar 2024 1 則可以顯示 2024 一月單月的月曆。

這操作起來比先前用的 ncal 好多了，先前用 cal 2024 會出現錯誤，因為只有一個參數時他會當作月份，而兩個參數時要把月份放前面，也就是用 cal 1 2024 才能正確顯示。

所以就把本來的 ncal 移除掉，改用 alias 來處理：「Add alias "cal".」。

其他的大多都有習慣的工具了，像是 base64 可以用 openssl base64 處理；而 json.tool 有 jq 可以用。

OpenLLM，用 Python 包裝 open source LLM 的套件

在 Hacker News 上看到「OpenLLM (github.com/bentoml)」，是一個用 Python 寫的軟體，把 open source LLM 包裝起來讓你用。

先拿 Mac 簡單測了一下，看起來包的不錯，可以用 HTTP API 來打。

先用 pip 裝：

pip install openllm

然後就可以把 server 跑起來了，依照範例跑 dolly-v2，第一次跑會比較久，需要下載 model：

openllm start dolly-v2

接下來就可以直接開 http://127.0.0.1:3000/ 來操作了，另外也可以用 command line 跑，像是依照官方的範例來跑：

openllm query --endpoint http://127.0.0.1:3000 "What is the meaning of life?"

目前測到比較明顯的問題是 CPU 模式下只有 single thread，所以雖然會動，但相當慢... 之後再來測試 GPU 的部分。

Python 的原生 multithreading 支援

在 Simon Willison 這邊看到的：「Real Multithreading is Coming to Python - Learn How You Can Use It Now」，他引用的原文在「Real Multithreading is Coming to Python - Learn How You Can Use It Now」這邊，在講 Python 3.12 將會有原生 multithreading 支援。

Python 裡知名的 GIL 問題將會用 Per-Interpreter GIL 的技術來解決，把 GIL 的 global-based 改寫變成 thread-based：

With introduction of "Per-Interpreter GIL", individual Python interpreters don't share the same GIL anymore. This level of isolation allows each of these sub-interpreters to run really concurrently.

這算是基礎建設，之後應該會有蠻長的陣痛期要轉換，尤其是各個其他程式語言寫的 library 要考慮到 thread-safe 的問題。

話說回來，PHP 就沒繼續討論過 threading 這個問題了，大家還是繼續用 process 架構在搞 XD

Ruff：用 Rust 寫的 Python Linter

在 Hacker News Daily 上看到「Astral (astral.sh)」這個，網站在「Astral: Next-gen Python tooling」。

裡面提到的 Ruff 專案是一套用 Rust 寫的 Python Linter，主打就是速度，從官網提供的 benchmark 就可以看出來差距：

因為是 Python ecosystem 的東西，安裝可以直接用 pip 裝預設編好的套件，而不需要透過 cargo 自己編 (當然你想要還是可以用 cagro 編)。

拿 feedgen 測了一下，速度是真的快，這樣就比較不會嫌棄了... 要注意會冒出 .ruff_cache/ 目錄，.gitignore 要加一下。

然後用預設值先掃出 unused import 修掉，其他的有機會再看要怎麼改。

MariaDB 以及 Trac 在 arm64 上的安裝

把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.micro (都是 1GB RAM)。

就效能上來說，t4g 機器的效能很不錯，這兩年 blog 跑的也都還算順，先前公司用起來感覺也很好，然後價錢更便宜，另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢，算是會想要換的主因。

在確認應用跑得起來後，買三年 RI 是 $87.15/3y，所以機器本身的費用大約是 $29.05/y，就算加上 8GB 的 EBS (gp3) 空間費用，整體比本來在 Vultr 的 $6/mo 低不少。

上面跑的是我自己的 Trac，想搬到 AWS 上一陣子了，但有幾個不確定的因素，所以連假期間才有空多花一些時間確認。

第一個是 MySQL 的部份，我自己習慣用 Percona Server 的版本，但目前還沒有 arm64 的套件可以直接裝，要用的話就得自己編以及升級。

在 2021 年的時候 blog 搬到 AWS 的時候就遇過了，本來以為這次有機會，但看了一下還是沒支援，所以還是得用 MariaDB。

第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情，但看起來官方的動力也不大...)，這在 18.04 的時代是沒什麼問題，但 22.04 下面不知道會爛掉多少東西。

所以只能繼續用 pyenv 扛著，但已經有預期會遇到問題，加上這次又從 MySQL 轉到 MariaDB，應該也會有些地雷...

所以跳下去後遇到的問題就跟上面提到的類似，分成兩塊。

在 MariaDB 這邊第一個遇到問題是，雖然官方有提供 APT server，但沒有在 HTTPS server 上放新的 public key，所以一定得從 key server 撈。

但 GnuPG 就是沒有直接從 key server 下載變成檔案的功能，一定要先塞到 keystore 裡面再 export 出來，就覺得很...

所以就冒出利用 mktemp -d 在 /tmp 下產生暫存目錄這樣的寫法，讓 GnuPG 把 keystore 放進去，這樣至少在重開機後就會消失：

export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME

這邊為了安全性，還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8。

另外就是整理 MariaDB 需要的 my.cnf 內容，我是拿 Percona Server 5.7 的設定檔來改，只刪掉了跟 GTID 相關的設定就會動了。

而其他 MariaDB 遇到的問題主要是設計改變的問題，在 wiki 上有提到。

接下來是 Trac 1.4 的問題，本來的安裝是用 libmysqlclient-dev，然後再安裝 mysql-python：

sudo apt install -y libmysqlclient-dev
pip install mysql-python PyMySQL Pygments Trac

但單純把 libmysqlclient-dev 換成 libmariadb-dev 後，mysql-python 還是編不動，照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過，最後找資料發現要改用 mysqlclient：

sudo apt install -y libmariadb-dev
pip install mysqlclient PyMySQL Pygments Trac

搞定後後續就一路看錯誤訊息解就可以了...

拿 JupyterLab 生一些圖

先前看到「Python Data Visualisation」這篇就在研究要怎麼在 Linux 桌面環境下用 Python 搭配 Altair 生圖，在寫一些文件的時候會方便一些。

但先前一直卡住 (不是生不出來，而是流程不順)，所以就放在 browser tab 上面一直沒動。直到前幾天看到 JupyterLab Desktop 改版，想說來看看改得如何：「Introducing the new JupyterLab Desktop!」。

先講一下結論，安裝不算太困難，界面也不差 (畢竟是重點)，但 interface bug 很多，常常按下去沒反應 XD

第一次跑的時候我先把 Python 的環境指到 pyenv 的 ~/.shim/python3。

先拿文章裡的範例丟進去跑：

import altair as alt
from vega_datasets import data

source = data.stocks()

alt.Chart(source).mark_line().encode(
    x='date',
    y='price',
    color='symbol',
    strokeDash='symbol',
)

會長這樣：

然後輸出圖表的右邊的 menu icon 展開後可以選 Save as PNG 存成圖片。

雖然不能直接存到 clipboard 方便我直接貼到 Imgur，但至少可以先打磨出想要的圖，再輸出成檔案處理...