Tag: python

Django 3.2 LTS

Django 3.2 LTS 出了：「Django 3.2 released」，對應的 release note 可以在「Django 3.2 release notes」這邊看到。

這個版本比較特別，一般版本提供大約 15 個月的支援，LTS 版本則提供 36 個月的支援，不過目前用起來的感覺還是鼓勵大家平常就要安排升級計畫，不然 3.2 升級到 4.2 鐵定是個超痛苦的過程。

昨天把 Django 3.1 的專案升級上 3.2 後，跑 test case 就遇到「Customizing type of auto-created primary keys」這邊描述的問題，目前先用 DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' 解，其他的倒是沒什麼問題...

幾個我覺得有趣的，像是 JSONL 格式：

The new JSONL serializer allows using the JSON Lines format with dumpdata and loaddata. This can be useful for populating large databases because data is loaded line by line into memory, rather than being loaded all at once.

然後不支援 PostgreSQL 9.5 與 MySQL 5.6 了：

Upstream support for PostgreSQL 9.5 ends in February 2021. Django 3.2 supports PostgreSQL 9.6 and higher.

The end of upstream support for MySQL 5.6 is April 2021. Django 3.2 supports MySQL 5.7 and higher.

很久前寫 Django 1.x，然後就荒廢很久，最近是從 3.0 開始寫，有些東西熟一點以後覺得怪怪的，之後要找時間測一些東西，修正對 Django 的用法。

檔案壓縮順序造成壓縮率的差異

Hacker News Daily 上看到「Why are tar.xz files 15x smaller when using Python's tar library compared to macOS tar?」這篇，作者問了為什麼他用 Python 的 tarfile 壓出來比起用 tar 壓出來小了 15 倍，檔案都是 JSON 檔壓成 XZ 格式：

I'm compressing ~1.3 GB folders each filled with 1440 JSON files and find that there's a 15-fold difference between using the tar command on macOS or Raspbian 10 (Buster) and using Python's built-in tarfile library.

看到 1440 個檔案應該會有直覺是一分鐘一個檔案，跑一天的量...

隔天他把原因找出來了，在裝了 GNU Tar 並且加上 --sort='name' 參數後，壓出來的大小就跟 Python 的 tarfile 差不多了：

Ok, I think I found the issue: BSD tar and GNU tar without any sort options put the files in the archive in an undefined order.

After installing GNU tar on my Mac with:

brew install gnu-tar

And then tarring the same folder, but with the --sort option:

gtar --sort='name' -cJf zsh-archive-sorted.tar.xz /Users/user/Desktop/temp/tar/2021-03-11

I get a .tar.xz archive of 1.5 MB, equal to the archive created by the Python library.

底層的原因是檔名與檔案內容有正相關的相似度 (因為裡面都是 sensor 資料)，依照檔名排序壓縮就等於把類似的 JSON 檔案放在一起壓，使得 xz 可以利用這點急遽拉高壓縮率：

My JSON files contain measurements from hundreds of sensors. Every minute I read out all sensors, but only a few of these sensors have a different value from minute to minute.

By sorting the files by name (which has the creation unixtime at the beginning of it), two subsequent files have very little different characters between them. Apparently this is very favourable for the compression efficiency.

遇到類似的情境可以當作 tuning 的一種，測試看看會不會變小很多...

Raspberry Pi 推出 MCU 產品 Pico

Raspberry Pi 推出了新的產品線 Raspberry Pi Pico，基於 ARM 架構的 MCU (microcontroller unit)，Hacker News 上也有不少討論：「Raspberry Pi Pico and RP2040 Microcontroller (raspberrypi.org)」。

與 Raspberry Pi 的 Zero 系列比起來，Zero 上面有 512MB RAM，不算大但還是可以跑一個完整的 OS。而 Pico 的定位就直接是 MCU 了，基本上就是特製的系統。

再來是看 Pico 的規格，比隔壁棚的 ESP32 低一些，但可以看出來 Pico 主要的定位還是教學：高速雙核心 CPU、多腳位、大的記憶體以及 flash (對於一般量產的 MCU 來說)，支援透過 Micro-USB 的 5V 供電界面方便開發與使用。

官方支援 C 與 MicroPython 兩種開發使用的模式，其中在 Hacker News 上有人抱怨 MicroPython 哭爸慢，不過這點應該還好，要在上面跑比較複雜的人會自己跳到 C 上面開發。

最後來講價位，目前定價是每顆 USD$4，當然跟一般商用量產的 MCU 差不少 (會盡可能壓低到「剛好夠用」的等級，價錢就有可能低到 USD$0.x)，但相比於現在在教學上很紅的 ESP32 (大約在 USD$10 附近) 來說，等於是殺出另外一條產品線，加上挾帶著 Raspberry Pi 的知名度來說，等於是讓更多人熟悉 MCU...

一人團隊的技術架構

Hacker News Daily 上看到的文章，在講一人團隊時所設計的技術架構：「The Tech Stack of a One-Man SaaS」。這種資訊通常帶有個人偏好，維護成本算是蠻重要的重點，在多人團隊就未必會這樣選，但就拿著爆米花看戲的心態來說應該還 OK。

像是作者很明顯熟悉 Python，就可以看到他裡面會列出許多 Python 相關的 toolchain 與維護工具。

裡面比較有趣的是他對 DigitalOcean 的 K8S 問題很多抱怨了一番，然後換去 Linode 後又因為不想要自己管 PostgreSQL 而決定搬到 AWS 上面，可以用 RDS 省事... 花錢解決 XD

算是當短文小說在看...

日本郵政的 CSV 資料

看到「Parsing the Infamous Japanese Postal CSV」這篇在抱怨日本郵政提供的 CSV 資料超級糟糕的問題覺得頗「有趣」的，在 Hacker News 上也有人「同病相憐」XDDD：「Parsing the Infamous Japanese Postal CSV (dampfkraft.com)」。

文章作者是「posuto」這個套件的維護人，這個套件讓開發者可以很方便的在 Python 下從郵遞區號推出對應的地點資訊：

import posuto as 〒

? = 〒.get('〒105-0011')

print(?)
# "東京都港区芝公園"
print(?.prefecture)
# "東京都"
print(?.kana)
# "トウキョウトミナトクシバコウエン"
print(?.romaji)
# "Tokyo To, Minato Ku, Shibakoen"
print(?.note)
# None

作者建立的資料是從「読み仮名データの促音・拗音を小書きで表記するもの(zip形式)」這邊取得並且分析，然後這篇文章就是在描述這些 CSV 檔的資料裡面有超級多奇怪的例外，用機器讀取超哭爸的 XDDD (好像不怎麼意外？)

不過最有趣的應該還是他提到的這個：

Oh, and if you need a Win3.1 or DOS program to copy the data onto an IBM H floppy disk, just check the bottom of JP Post's page - they've got you covered.

看起來是頁面下方的這塊：

這就真的太哭爸了啊 XDDD

Python 3.9.0 以及 3.10.0a1

Python 3.9.0 出了：「Python 3.9.0 is now available, and you can already test 3.10.0a1!」。

下一個版本是 3.10 而非 Python 4：

OK, boring! Where is Python 4?

Not so fast! The next release after 3.9 will be 3.10. It will be an incremental improvement over 3.9, just as 3.9 was over 3.8, and so on.

在「What’s New In Python 3.9」裡面的「Optimizations」這段有測一些基本操作的效能，可以看到 Python 3.9 其實比 Python 3.8 慢了一些？好像也沒有提到原因就是了...

Facebook 放出 Pysa，靜態分析 Python 程式碼的工具

Facebook 丟出來的靜態分析工具，可以拿來分析 Python 程式碼：「Pysa: An open source static analysis tool to detect and prevent security issues in Python code」，專案在「facebook/pyre-check」這邊可以取得。

不過軟體居然是用 OCaml 寫的啊，另外已經包好了，可以用 pip 直接裝 pyre-check。

官方的說明裡面有提到要裝 watchman，不過這算是選擇性安裝，不裝 watchman 直接執行也可以用，只是會跳個訊息跟你說裝了可以遞增檢查：

To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install

最近在寫的專案都是用 Python，剛好可以拿來掃這些專案...

Django 3.1

看到「Django 3.1 Released」這邊的公告，比較完整的改變可以在「Django 3.1 release notes」這邊翻到。

這應該是第一次要把手上的專案跳 minor version 升級，看起來應該是還好，但天曉得會有什麼狀況... 看起來主要會是 sha1 要被換成 sha256 會有影響到。

另外看到這個：

SimpleTestCase now implements the debug() method to allow running a test without collecting the result and catching exceptions. This can be used to support running tests under a debugger.

看起來應該也蠻有用的，可以玩看看...

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