幹壞事是進步最大的原動力
在 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 裡面跑。
銀河的歷史又翻過了一頁...
看到「A lightweight python3 library for arithmetic with real numbers.」這個有趣的 Python 延伸套件，可以用他進行高精度的實數運算...
一開始在 Python 3.9 環境裝，結果就跳出需要 3.10+ 的環境，想了一下，開了一個 Docker container 裝 pyenv 來測，測過以後覺得還蠻有趣的，看起來之後把預設環境變成 3.10+ 應該會裝起來用...
這個 reals 的重點在於保證顯示數字的正確性：
It allows you to compute approximations to an arbitrary degree of precision, and, contrary to most other libraries, guarantees that all digits it displays are correct.
目前支援的常數與操作有這些：
Constants: pi, e, phi
Functions related to powers: sqrt, exp, log
Operators: negation, addition, subtraction, multiplication, division, powers
Trigonometric functions: sin, sinh, csc, csch, cos, cosh, sec, sech, tan, tanh, cot, coth
用法的部份，先把 reals 拉進來：
>>> from reals import sqrt
然後用法算直覺：
>>> sqrt2 = sqrt(2) >>> sqrt2 <reals._real.Real object at 0x10d182560 (approximate value: 1.41421)>
>>> sqrt2.evaluate(10)
'1.4142135624'
>>> '{:.10f}'.format(sqrt2)
'1.4142135624'
>>> sqrt2.to_decimal(10)
Decimal('1.4142135624')
不過作者有提到效能沒有處理到很好，所以應該是拿來快速做一些運算得到結果而已。
Pyston 專案是一個想要提供更快速的 Python，而前陣子決定改變開發的方向：「Announcing 3.7-3.10 support and a new direction」。
本來的 Pyston-full 是直接修改 CPython 的 codebase 加速：
Our original product, which we’re retroactively calling Pyston-full, is a fork of the entire CPython codebase. Having users install a fully-custom version of Python lets us make changes across the Python implementation, leading to the most optimizations and largest speedups.
但這種方式的安裝與維護都需要另外搞，而且因為 ABI 不相容的問題，遇到一些套件可能會需要自己編 (甚至自己改？)，不能直接用編好的 binary：
The flip side is that it is fairly intensive to set up. While we believe Pyston-full is one of the most highly-compatible alternative Python implementations available, it can be difficult to switch Python implementations regardless of the ease of use of either implementation. Compounded on this, we decided to break the ABI which requires users to recompile extension modules. In theory this is not a big deal, but in practice the lack of available binary packages is a significant disincentive to use an alternative implementation.
這樣雖然有 30% 的效能提昇，但對使用者的吸引力不高，所以打算要轉變方向，讓使用者更容易使用，這也是決定發展可以用 pip 安裝的 Pyston-lite 版本：
The sum of all of this was that while we were very happy to achieve a 30% speedup with Pyston-full, it was very difficult to get people to start using it. We decided to try a different form factor: a pip-installable extension module called Pyston-lite.
但效能的提昇就不像 Pyston-full 這麼高，Pyston-lite 只剩下 10% 了：
So while it’s a bit difficult to accept that we are now providing a 10% speedup instead of 30%, we’ve decided that it’s much more important to provide something that people are willing to use.
另外在文末有列出各版本的效能提昇 (與 CPython 3.8 比較)，可以看到 CPython 3.11rc2 的提昇其實跟 Pyston-lite 差不多，除非 Pyston-lite 可以把效能疊加上去，不然就有點尷尬了：
但 Pyston 要支援 3.11 看起來會花不少功夫：
In the longer-term future we are planning to submit our JIT upstream as well, but we expect retargeting it to 3.11 to be significantly more work than the other versions due to the extensive amount of changes that were made to the interpreter in that version.
不過手上一些既有的東西好像可以掛上去測看看...
在 Hacker News Daily 上看到「From Oscilloscope to Wireshark: A UDP Story」這篇講怎麼用示波器挖出 UDP 封包的方法。不是用邏輯分析儀，而是用示波器...
上面示波器的圖片可以查到作者是用 Tektronix 的 6 Series MSO，看起來停賣了，但類似的型號應該是百萬等級...
所以真的是打算從 L1 層一路解到 L4 層：
The rest of this post will take us from these raw voltage waveforms all the way to decoded UDP packets. Hold on tight, we're going from L1 all the way to L4.
網路設備是 VSC7448 這顆 52-port 10Gbps switch：
不過這邊提到一秒可以打 30K 的 UDP 封包出來，對於這台 switch 應該是沒滿才對，而且速度上應該也不到 10Gbps，加上作者提到的是 QSGMII，有可能是跑 1Gbps 的速度在抓：
The oscilloscope doesn't have a built-in QSGMII analyzer (and we'll want to do fairly sophisticated processing of the data), so I wanted to export waveform data to my computer.
I knew that a device on the network was emitting about 30K UDP packets per second, or one packet every 33 µs. I configured the oscilloscope to collect 100M samples at 1 TSPS (tera-sample per second, 1012), which multiplies out to 100 µs of data; this means we should catch 1-3 UDP packets.
看起來只是抓個意思意思練練手而已，抓 1 到 3 個 UDP 封包。
後面就是一堆數學處理... 看起來前面有一小段程式碼是 Python，但後面的程式碼有人知道是什麼語言嗎？
幾個禮拜前看到「Show HN: I stripped DALL·E Mini to its bare essentials and converted it to Torch (github.com/kuprel)」這個東西，有訓練好的 model 可以直接玩文字轉圖片，GitHub 專案在「min(DALL·E) is a fast, minimal port of DALL·E Mini to PyTorch」這邊可以取得。
因為這是包裝過的版本，裝起來 & 跑起來都很簡單，但沒想到桌機的 1080 Ti 還是跑不動，只能用 CPU 硬扛了，速度上當然是比官網上面列出來用 GPU 的那些慢很多，但至少能跑起來玩看看。
首先是拿官方的句子來玩看看，第一次跑會需要下載 model (會放到我們指定的 pretrained 目錄下)：
#!/usr/bin/env python3
from min_dalle import MinDalle
import torch
model = MinDalle(
models_root='./pretrained',
dtype=torch.float32,
device='cpu',
is_mega=True,
is_reusable=False,
)
images = model.generate_image(
text='Nuclear explosion broccoli',
seed=-1,
grid_size=2,
is_seamless=False,
temperature=1,
top_k=256,
supercondition_factor=32,
is_verbose=False,
)
images = images.save('test.png')
我自己在下載過後，跑每個生成大概都需要十分鐘左右 (參數就像上面列的，CPU 是 AMD 的 5800X，定頻跑在 4.5GHz)，出來的結果是這樣：
接著是一些比較普通的描述，這是 sleeping fat cats：
然後來測試看看一些比較偏門的詞，像是 Lolicon，這個就差蠻多了：
但感覺有蠻多應用可以掛上去，這樣有點想買張 3090 了...
AWS 推出了 Amazon CodeWhisperer，可以看做是 GitHub Copilot 的競爭產品：「Now in Preview – Amazon CodeWhisperer- ML-Powered Coding Companion」，在 Hacker News 上的討論還不多：「Copilot just got company: Amazon announced Codewhisperer (amazon.com)」。
目前還是 Preview 所以是免費的，但也還沒有提供價錢：
During the preview period, developers can use CodeWhisperer for free.
另外目前提供的程式語言只有 Python、Java 與 JavaScript：
The preview supports code written in Python, Java, and JavaScript, using VS Code, IntelliJ IDEA, PyCharm, WebStorm, and AWS Cloud9. Support for the AWS Lambda Console is in the works and should be ready very soon.
至於 training 的資料集，這邊有提到的是 open source 專案與 Amazon 自家的東西：
CodeWhisperer code generation is powered by ML models trained on various data sources, including Amazon and open-source code.
開發應該需要一段時間，不知道是剛好，還是被 GitHub Copilot 轉 GA 的事件強迫推出 Preview 版...
在 Daily Lobsters 上看到「Solving Sudoku with Poetry's dependency resolver」這篇完全是惡搞 Python 下 Poetry 套件 XDDD
作者搞出來的方法是這樣，指定 81 個版號來表示題目，然後跑 Poetry 找可以的版本組合：
[tool.poetry.dependencies] python = "^3.6" sudoku-cell11 = "*" sudoku-cell12 = "2.0.0" sudoku-cell13 = "*" sudoku-cell14 = "8.0.0" sudoku-cell15 = "*" sudoku-cell16 = "9.0.0" sudoku-cell17 = "*" sudoku-cell18 = "*" sudoku-cell19 = "*" sudoku-cell21 = "3.0.0" sudoku-cell22 = "7.0.0" sudoku-cell23 = "*" sudoku-cell24 = "6.0.0" ...
另外作者有提到，本來是打算用 Yarn 來解，但看起來各種嘗試都會搞爆 Yarn，才換到 Python 上面玩 XD
在 Hacker News 上看到「Python 3.11 Performance Benchmarks Are Looking Fantastic」這篇，提到目前還在 beta 的 Python 3.11 效能已經比 Python 3.10 有大幅進步了：
Python 3.11 is 10~60% faster than Python 3.10 according to the official figures and a 1.22x speed-up with their standard benchmark suite.
HN 上對應的討論在「Python 3.11 Performance Benchmarks Are Looking Fantastic (phoronix.com)」。
從比較簡單的 PyBench 到 Python 官方的 pyperformance 都有大幅進步。
像是 PyBench：
然後 pyperformance 的部份挑個我自己用到比較多的，Django 相關的東西：
整體分數跑幾何平均的話會是：
When taking the geometric mean of all the Python benchmarks I carried out for this article on the AMD Ryzen 9 5950X, Python 3.11 Beta was about 41% faster overall than the current Python 3.10.4 stable release or 45% over the aging Python 3.8 series.
在官方文件上「Faster CPython」這邊有提到做了哪些事情，可以看到大家分頭去改善超多東西，累積起來就很驚人...
在 Hacker News 首頁上看到「no-op statements syntactically valid only since Python X.Y」這個專案，搞爆各個版本 Python 的各種方式，從 Python 2.4+ 一路到 3.11+ (不過中間有少了 3.2 與 3.4)。
專案要求的條件是 no-op，所以像是 import 這種行為都會產生 side effect，所以就不能用 sys.version_info 這個變數了：
This is a collection of no-op statements that are syntactically valid only since Python X.Y, for most X.Y ≥ 2.4.
看了一下裡面的例子，反而看到一些有趣的東西，像是原來這種語法在 Python 2.3 是不能跑的：
(0 for x in []) # Python >= 2.4 is required
然後 0_0 這種方便表示數字的寫法在 Python 3.6+ 才能動：
0_0 # Python >= 3.6 is required
有些東西真的是用習慣就忘記了，遇到一些古董環境可能會中獎然後在那邊疑惑半天 XD
看起來這個專案應該比較偏娛樂性質？實際應用上有很多其他比較常見的方式檢查環境才對 XD 但馬上想到，在打黑箱的時候可以用這個方法判斷 Python 的環境版本？
前幾天的 Hacker News Daily 上看到的東西，是由 Bloomberg 開發出來的工具 Memray，這個工具是一個 Python 套件：
Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself.
套件有多種輸出，其中一種是可以產生出記憶體使用情況的 flamegraph，轉成圖檔後像是這樣：
官方支援 Python 3.7+：
Memray requires Python 3.7+ and can be easily installed using most common Python packaging tools.
用法看起來也很簡單，之後如果有需要看 memory footprint 的情況好像可以拿來用看看...