Tag: python

AWS 也推出了 GitHub Copilot 的競爭對手 Amazon CodeWhisperer

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 版...

用 Poetry 的相依性演算法解數獨 (Sudoku)

在 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

Python 3.11 (目前還是 beta) 的效能大幅進步

在 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」這邊有提到做了哪些事情，可以看到大家分頭去改善超多東西，累積起來就很驚人...

搞爆 Python 的各種姿勢

在 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 的環境版本？

畫 Python 下記憶體使用情況的 Flamegraph：Memray

前幾天的 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 的情況好像可以拿來用看看...

Python 裡使用超過 Double Precision 的運算

Hacker News 上爬到的，是一篇 2019 的文章：「When Double Precision Is Not Enough (adambaskerville.github.io)」，原文在「T>T: When Double Precision is Not Enough」。

作者是拿矩陣 (matrix) 的運算當例子，遇到了 double precision 造成的計算誤差問題：

There is no error with the program; this discrepancy is caused by a loss of numerical accuracy in the eigenvalue calculation due to the limitation of hardware double precision (16-digit).

解法是用 mpmath 增加精度，算是一種暴力解，到要注意計算會慢很多：

Note that this library is incredibly slow for large matrices, so is best avoided for most applications.

另外在 Hacker News 的討論串裡面看到個有趣的東西：「Herbie: Automatically Improving Floating Point Accuracy」這個專案，你把公式丟進去，Herbie 會試著提供等價公式來維持精度，像是 \sqrt{x+1} - \sqrt{x} = 1 / ( \sqrt{x+1} + \sqrt{x} ) 這種東西。

半自動化幫你改善...

一些不太容易注意到的 Python 安全性問題

前幾天看到「10 Unknown Security Pitfalls for Python」這篇，講 Python ecosystem 裡面的一些設計造成的安全性問題，裡面很多東西都很有趣，而且有些算是共通的，其他程式語言也會中獎...

第一個是開發者用 assert() 確認權限，但 assert() 的設計是 debug 用的功能，所以可以預期在 optimization 後會被拿掉 (其他程式語言也有類似的功能)，而導致權限沒被檢查而產生 security incident。

第二個是 os.makedirs() 所指定的 mode，依照說明看起來是 Python 改變行為了，變成只有最終的那個目錄照著設定：

In Python < 3.6, the folders A, B and C are each created with permission 700. However, in Python > 3.6, only the last folder C has permission 700 and the other folders A and B are created with the default permission 755.

這個設計就有點討厭了，我測了一下 umask 077 的情況下在 shell 下執行 mkdir a/b/c，所有的目錄都會是 700。

第三個是串檔名的 os.path.join()，遇到 / 開頭的部份會把前面的部份都拔掉，也就是這樣：(嗯... 這樣搞的嗎 XDDD)

>>> os.path.join('var', 'lib', 'tmp', 'abc.png')
'var/lib/tmp/abc.png'
>>> os.path.join('var', 'lib', 'tmp', '/etc/shadow')
'/etc/shadow'

第四個就是蠻標準的 variable injection 了。

第五個算是每次處理 .zip 檔都很頭痛的問題，不限於 Python，因為壓縮檔裡面可能會有 ../../ 開頭這種看起來就很邪惡的檔案名稱，只要有安全意識的工程師都覺得處理起來很麻煩的東西...

第六個一看就是壞東西，想要用黑名單擋 injection 一定會有更多有創意的方法打進來。比較特別的是這邊有提到在 Python 裡 re.search() 與 re.match() 的差異，這點真的是寫起來有時後會忽略掉的...

第七與第八個都是 Unicode 相關的問題，也是個超級麻煩的東西，大原則是先 normalize 再 escape，但還是有點見招拆招去看...

第九個也是類似的問題，沒有先 normalize 再確認，不過一般機器都會有 private ip address，還是可以試著打... 這個有機會用架構面去解決，像是用 MQ 架設 proxy service，隔出另外一區來跑；或是已經有 zero trust 的架構，內部網路也是要帶 token 跑來跑去，可以減少一些傷害...

第十個算是 Python 自己的歷史因素，早期同時吃 & 與 ; 當作 separator，而非只吃 & 的 x-www-form-urlencoded (HTML spec 內定義的標準)：

In Python < 3.7 the function urllib.parse.parse_qsl allows the use of the ; and & characters as separators for URL query variables.

查了一下官方文件可以看到 3.10 之後才變成 x-www-form-urlencoded：

Changed in version 3.10: Added separator parameter with the default value of &. Python versions earlier than Python 3.10 allowed using both ; and & as query parameter separator. This has been changed to allow only a single separator key, with & as the default separator.

有些應該是有安全意識時會去翻 spec 看看就可以避開的，但有些就真的是蠻雷的 XDDD

Python 的 Black

在 Hacker News 上看到 Black 這個幫你處理 Python 程式碼的工具：「Black, the uncompromising Python code formatter, is stable (pypi.org)」。

Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

然後從 Hacker News 上討論的情況看起來大家都覺得很不錯？好像可以看看能不能拿來用...

另外一個在討論的時候看到學到的東西，是 git blame --ignore-revs-file 這個功能，可以在 git blame 時濾掉某些 commit，剛好拿來過濾 reformatting commit：

Ignore revisions listed in file, which must be in the same format as an fsck.skipList. This option may be repeated, and these files will be processed after any files specified with the blame.ignoreRevsFile config option. An empty file name, "", will clear the list of revs from previously processed files.

Fork 自微軟的 Pyjion 專案的 Python 3.10 + JIT 方案

在 Hacker News 上看到「Pyjion – A Python JIT Compiler (trypyjion.com)」這個專案，也是一個想要透過 JIT 加速 Python 的專案：

Pyjion is a drop-in JIT Compiler for Python 3.10. It can be pip installed into a CPython 3.10 installation on Linux, Mac OS X, or Windows.

看了一下是從微軟的 Pyjion 專案 fork 出來的，原來的專案最後一次 commit 是一年前，而且專案也已經標示為 archived (read-only mode)，但有留下轉移的說明，也就是上面提到的專案：

Development has moved to https://github.com/tonybaloney/Pyjion

可以看到大部分的效能都已經進入改善階段 (很多導入 JIT 的專案在初期時會先變慢)：

跟其他的 JIT 方案相比，Pyjion 的目標是高度相容現有 Python 的程式，包括各種 extension，這點的確是在用 PyPy 這些軟體時的痛點沒錯...

看起來透過 pip 裝好後就可以直接 import 進來用，後續就會生效：

import pyjion; pyjion.enable()

另外提一下，翻 Hacker News 留言的時候翻到這個害我笑出來，有夠新 XD

zatarc 3 days ago | unvote | prev | next [–]

Pyjion requires: CPython 3.10 and .NET 6

.NET 6 Release: 19 hours ago (https://github.com/dotnet/core/blob/main/release-notes/6.0/6...)

... ok.

PyPy JIT 的改善

在 PyPy 這邊看到 JIT 的重大進展：「Better JIT Support for Auto-Generated Python Code」。

他們在 Tornado 上重製出來效能問題，後面也都是用這個例子在測試：

If you render a big HTML template (example) using the Tornado templating engine, the template rendering is really not any faster than CPython.

看起來上的 workaround 是在撞到 trace limit 時標記起來，之後再遇到時就可以跳進 special mode，接著處理下去避免浪費掉之前處理過的 trace：

After we have hit the trace limit and no inlining has happened so far, we mark the outermost function as a source of huge traces. The next time we trace such a function, we do so in a special mode. In that mode, hitting the trace limit behaves differently: Instead of stopping the tracer and throwing away the trace produced so far, we will use the unfinished trace to produce machine code.

效能可以看到改善很多：

看起來這個概念有打算在 3.8 的時候放進去：

The work described in this post tiny bit experimental still, but we will release it as part of the upcoming 3.8 beta release, to get some more experience with it. Please grab a 3.8 release candidate, try it out and let us know your observations, good and bad!

Django 的 template engine 不怎麼快，用 Jinja2 可能是一個方法，但既有的 project 如果有遇到 template engine 的效能問題，也許也可以翻看看 PyPy 解得如何...