Python 上的 OCR

這個 OCR 專案是在 Python 包好,讓你很快就可以上手用:「Easy OCR」。

從結果的 screenshot 可以看到輸出的內容很簡單,就是座標與 OCR 出來的內容:

然後支援的語言很多:

We are currently supporting following 42 languages.

Afrikaans (af), Azerbaijani (az), Bosnian (bs), Simplified Chinese (ch_sim), Traditional Chinese (ch_tra), Czech (cs), Welsh (cy), Danish (da), German (de), English (en), Spanish (es), Estonian (et), French (fr), Irish (ga), Croatian (hr), Hungarian (hu), Indonesian (id), Icelandic (is), Italian (it), Japanese (ja), Korean (ko), Kurdish (ku), Latin (la), Lithuanian (lt), Latvian (lv), Maori (mi), Malay (ms), Maltese (mt), Dutch (nl), Norwegian (no), Polish (pl), Portuguese (pt),Romanian (ro), Slovak (sk) (need revisit), Slovenian (sl), Albanian (sq), Swedish (sv),Swahili (sw), Thai (th), Tagalog (tl), Turkish (tr), Uzbek (uz), Vietnamese (vi)

有些參數可以調整,但預設值似乎就跑得不錯了...

在瀏覽器內跑 Python

看到「A Python 3 implementation for client-side web programming」這個專案,在瀏覽器裡把 Python 程式碼用 <script type="text/plain"></script> 包起來,然後掛個 js 進去,就可以在瀏覽器裡面跑 Python 操作 DOM:

Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation (you can take it for a test drive through a web console), adapted to the HTML5 environment, that is to say with an interface to the DOM objects and events.

另外在 Brython 3.8.9 performance compared to CPython 3.8.0 這頁也有跟 CPython 的比較 (看起來是用 Firefox 測的),其實速度看起來不慢?我猜是 JS 這邊的軍備競賽把整個引擎弄的超快 XDDD

讓 Python 輸出變豐富的 Rich

Hacker News 上看到的 Python 專案,讓 terminal 輸出變得更好看:「Rich is a Python library for rich text and beautiful formatting in the terminal.」。

看到當下吸引我的地方在於表格:

from rich.console import Console
from rich.table import Column, Table

console = Console()

table = Table(show_header=True, header_style="bold magenta")
table.add_column("Date", style="dim", width=12)
table.add_column("Title")
table.add_column("Production Budget", justify="right")
table.add_column("Box Office", justify="right")
table.add_row(
    "Dev 20, 2019", "Star Wars: The Rise of Skywalker", "$275,000,000", "$375,126,118"
)
table.add_row(
    "May 25, 2018",
    "[red]Solo[/red]: A Star Wars Story",
    "$275,000,000",
    "$393,151,347",
)
table.add_row(
    "Dec 15, 2017",
    "Star Wars Ep. VIII: The Last Jedi",
    "$262,000,000",
    "[bold]$1,332,539,889[/bold]",
)

console.print(table)

輸出長這樣:

另外還有不少功能也不錯,會讓畫面豐富不少。

用 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 了,翻了一下目前的情況,好像就是放著,不知道會有什麼方案搬出來...