用 Python 刻 GUI 的 guietta

Hacker News Daily 翻到的奇怪工具 guietta,可以在 Python 下用奇怪的方法刻 GUI,範例就很好解釋了調性:

from guietta import _, Gui, Quit

gui = Gui(
    
  [  'Enter numbers:', '__a__'  , '+' , '__b__',  ['Calculate'] ],
  [  'Result:  -->'  , 'result' ,  _  ,    _   ,       _        ],
  [  _               ,    _     ,  _  ,    _   ,      Quit      ]
)

with gui.Calculate:
    gui.result = float(gui.a) + float(gui.b)
    
gui.run()

然後 Ubuntu 下的輸出會是:

Hacker News 的討論串「Guietta – Python module to create simple GUIs (github.com)」這邊有人也介紹了其他 Python 下刻 GUI 的方式,翻了一下也還不少有趣的東西。

guietta 看起來拿來刻一些簡單的東西應該還算堪用,尤其是討論裡面有提到在教學授課時可以簡化不少 interface 的問題。

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 撐場了...

Python 3.7+ 保證 dict 內容的順序

在「Dicts are now ordered, get used to it」這邊看到的,因為 Python 官方 (也就是 CPython) 實做 dict 的方式改變,然後決定把這個特性當作是 social contract,而不是當作 side effect 的特性 (也就是不保證之後版本會有相同特性)。

Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.

作者裡面的兩張圖清楚表示出來以前的版本怎麼實做,與 3.7+ 的版本怎麼實做:

這樣就很好理解了。

不過考慮到還是有些系統用 Python 3.5 (像是 Ubuntu 16.04 內建的 python3) 與 Python 3.6 (Ubuntu 18.04 內建的 python3,雖然沒問題,但當時還沒有寫出來),也許還是先不要依賴這個行為會比較好。

不過以插入的順序列出好像不是很常用到...

MIT 的「The Missing Semester of Your CS Education」

MIT 推出的短期課程,在 CS 相關科系裡面不會教,但是如果學過的話會讓你的 CS 學習過程有很不一樣的改變:「The Missing Semester of Your CS Education」。

整個主軸是偏應用為主,其中花了很多篇章在講 CLI 下的工具,這點從每堂課的標題就可以看出來:

1/13: Course overview + the shell
1/14: Shell Tools and Scripting
1/15: Editors (Vim)
1/16: Data Wrangling
1/21: Command-line Environment
1/22: Version Control (Git)
1/23: Debugging and Profiling
1/27: Metaprogramming
1/28: Security and Cryptography
1/29: Potpourri
1/30: Q&A

我自己快速讀過去的時候發現,雖然這是入門課程,但我還是從裡面抓到了一些以前沒有關注的關鍵字 (像是 Python debugger pdb 與 profiling 相關的操作)。

接下來應該會開個連載來寫一下心得與感想...

Python 新的 HTTP client library:HTTPX

看到「A next-generation HTTP client for Python.」這個專案冒出來,宣稱是下一代 Python 的 HTTP client library:

HTTPX is a fully featured HTTP client for Python 3, which provides sync and async APIs, and support for both HTTP/1.1 and HTTP/2.

目前專案還在 beta,目標是在今年四月出 1.0 版。從說明裡面可以看到,目前的方向是打算相容 requests,讓現有的程式可以不用做太多修改就轉移過來。

再來從開發者的角度來看,HTTPX 比 requests 多了這些功能:

  • Standard synchronous interface, but with async support if you need it.
  • HTTP/1.1 and HTTP/2 support.
  • Ability to make requests directly to WSGI applications or ASGI applications.
  • Strict timeouts everywhere.

但如果就支援這些功能的角度來看,修改 requests 看起來應該會比較快?開新的專案感覺跟 Kenneth Reitz 有關...

Kenneth Reitz 有兩個很有名的作品,一個是這個,另外一個是 Pipenv,也就是在「pipenv 的凋零與替代方案 poetry」這邊提到的事情。

然後看了一下 CHANGELOG.md 內的資訊,裡面最早的記錄是 0.6.0 (2019/06/21),而從 Contributors to encode/httpx 這頁看起來則是 2019/03/31 開始發展的,就這些時間點看起來,原因大概跟 Kenneth Reitz 有關... 雖然沒有找到文章直接提到這件事情。

不過 HTTPX 需要 Python 3.6+ 才能跑,對於版本的要求比較高,如果是 16.04 預設的 python3 (3.5) 就沒辦法跑了,18.04 預設的 python3 (3.6) 也才剛好符合...

之後應該是 HTTPX 與 requests 兩邊都得關注了,看看會有什麼發展...

Python 2 的後續支援

雖然 2020/01/01 開始 Python 2 就沒有官方支援了 (翻了一下資料發現「Python 2 series to be retired by April 2020」這篇,官方好像延到四月了...),不過剛剛看到這則新聞,裡面提到了商業支援:「Snakes on a wane: Python 2 development is finally frozen in time, version 3 slithers on」。

在最後一段:

Those catering to corporate clients intend to continue support Python 2.7 for a while. In October, Red Hat said it will stop supporting Python 2.7 in RHEL 8 come June 2024.

不確定這些 patch 會不會也移植到 CentOS 上,如果會的話,至少有一個地方可以讓你多四年掙扎,感覺上可以用 container 生一個獨立的環境...

另外 Ubuntu 這邊的 LTS 不知道有什麼方案,已知 20.04 的目標是要移除掉,但 16.04 與 18.04 裡的 Python 2 如果有問題時,不知道會不會收 patch...

再來就是 pyenv 了,翻了一下目前的情況,好像就是放著,不知道會有什麼方案搬出來...

pipenv 的凋零與替代方案 poetry

看到「If this project is dead, just tell us」這個,裡面討論到了 pipenv 的前景愈來愈讓人疑惑,要官方給個意見,結果下面就馬上有人建議跳槽到 poetry

剛好前陣子看到另外一篇文章「My Python Development Environment, 2020 Edition」,裡面也提到了他把 pipenv 換成 poetry,而且提到了 pipenv 的問題:

pipenv → poetry. This move’s more complex. I stoped using Pipenv for a couple of reasons:

  • Governance: the lead of Pipenv was someone with a history of not treating his collaborators well. That gave me some serious concerns about the future of the project, and of my ability to get bugs fixed.
  • Bugs and rapid API changes. About a year ago, Pipenv had lots of bugs, and a rapid pace of change introducing or changing APIs. I ran into minor issues at least once a week. Nothing was seriously bad, but it generally felt fairly unstable. I kept having to update various automated deploy workflows to work around issues or changes to Pipenv.

看起來 tech stack 裡面要把 pipenv 轉移抽離了...

擋 Live 與 Podcast 內廣告的工具

看到「An adblocker for live radio streams and podcasts. Machine learning meets Shazam.」這個專案,這個把 machine learning 用到「正途」上了啊...

不過畢竟是比較複雜的演算法,會吃不少 CPU 資源:

On a regular laptop CPU and with the Python time-frequency analyser, computations run at 5-10X for files and at 10-20% usage for live stream.

不過看用法還是偏向 library 性質,如果要大力推廣可能還是需要有其他人包個更好的界面...

Trac 1.4

剛剛看到 Trac 出了 1.4 的消息,雖然還是在用 Python 2:「Release Notes for Trac 1.4 Jinja Release」。

其中一個比較大的改變是 template engine 換掉了,從 Edgewall 自家的 Genshi 換到 Jinja2 上,目前看起來兩者都可以用,但可以預期現有的 template 要找時間換過去:「5 times speed-up when rendering query results, thanks to the migration from Genshi to Jinja2.」。

其他的改變應該還好,找個週末來把自己的 Trac 備份起來測試好了...