`_pyrepl.input.KeymapTranslator` tests for non-existent Unicode category
還沒有人認領這個 Issue。
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 36k
- PR 合併指標
- PR 指標待擷取
描述
Bug report
Bug description:
The implementation of _pyrepl.input.KeymapTranslator has a check for input with Unicode category "C". This code has been present since the initial commit of the new REPL in #111567. However, no such category is ever returned by unicodedata because there is no "C" entry in the list of category names¹
>>> any(unicodedata.category(chr(n)) == "C" for n in range(sys.maxunicode)) # Python 3.12
False
I'm not familiar enough with _pyrepl to know what the implications of this always-false predicate are, but I do know that the block in question is effectively dead code because of it.
I think this is meant to be a .startswith() check for the Other category identified by UAX #44, i.e. the union of Cc | Cf | Cs | Co | Cn, in line with other usage in _pyrepl.reader. I'll open a PR for that.
¹ the list of category names is hardcoded in makeunicodedata.py rather than derived from UCD, which does define C = Cc | Cf | Cs | Co | Cn in PropertyValueAliases.txt. I don't think there's any version of the unicodedata API that would support returning "C" here, though. Just being a little obsessive.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs
- gh-123683
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
從 Lib/_pyrepl/input.py 的第 94-95 行開始,並比較 Lib/_pyrepl/reader.py 中相關的 Unicode 類別使用方式。驗證報告中描述的行為,並檢查相關的 _pyrepl 測試;當實作和測試正確反映預期的 Unicode 類別處理方式時,即表示完成。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- python
- 領域
- cli
- Issue 類型
- 缺陷
- 難度
- 2/5
- 預估耗時
- 1-3 小時
- 活躍度
- 停滯
- 描述清晰度
- 描述清楚
- 新手友好度
- 20/100