test_str: the UCS4 adaptive search path is never exercised
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with Lib/test/test_str.py beside test_find and review string_tests.BaseTest.test_adaptive_find to match its existing long-string setup. Add the proposed non-BMP character case and run the relevant string tests; done when the UCS4 adaptive search path is exercised. The issue says the author already has the change ready and plans to open a pull request.
由索引模型根据 Issue 内容生成。
描述
Summary
Objects/stringlib/fastsearch.h compiles adaptive_find once per character
width. The UCS4 copy never ran under the entire test suite, because the only test
that reaches the adaptive path, string_tests.BaseTest.test_adaptive_find, uses
ASCII strings.
Evidence
Coverage from a --coverage build of main running the full suite
(./python -m test -j4, 552 files, 52,070 tests):
Function 'ucs4lib_adaptive_find' Lines executed:0.00% of 39
Function 'ucs2lib_adaptive_find' Lines executed:66.67% of 39
Function 'ucs1lib_adaptive_find' Lines executed:71.79% of 39
Function 'asciilib_adaptive_find' Lines executed:79.49% of 39
Why the existing test misses it
The adaptive branch is taken only when, in Objects/stringlib/fastsearch.h:800:
- the haystack is at least 2500 characters,
- the needle is at least 100 characters (or the haystack at least 30000),
- the needle is at least a third of the haystack.
test_adaptive_find meets all three, but with 'a' and 'b', so the code that
runs is the ASCII or UCS1 instantiation. Nothing in the suite builds a haystack
that wide-and-long out of non-BMP characters, so the UCS4 instantiation stays
cold.
Proposal
Add a test next to test_find in Lib/test/test_str.py that repeats the same
shape with '\U0001d11e' and '\U0001d11f'. With that test present,
ucs4lib_adaptive_find goes from 0.00% to 89.74% of 39 lines, and the remaining
branches are the count and reverse-search modes, which are separate entry points.
This is a test-only change, so it does not alter behaviour. I have it ready and
will open a PR against this issue.
CPython versions tested on
CPython main branch (3.16.0a1+)
Operating systems tested on
Linux
Linked PRs
- gh-160502
- 主要语言
- Python
- 星标
- 77.7k
- 派生
- 38.3k
- 平均合并
- 13 小时 30 分钟
- 30 天内合并 PR
- 708
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
python/cpython 的其他 Issue
-
tarfile: extractfile(member).read() of a sparse member is slow due to repeated bytes concatenation未关闭performance stdlib
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
tests topic-profiling type-bug
难度 2/5 1-3 小时 新手友好度 78/100
python/cpython#160334 · 1 条评论 ·
维护者通常 1 天内回复
-
`iso2022_jp_3` encodes U+9B1D but decodes the result as U+9B1C可能已有人在做 @kinqsradio 于 2 天前认领。 未关闭extension-modules type-bug
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
interpreter-core type-feature
难度 1/5 1 小时以内 新手友好度 78/100
python/cpython#160109 · 1 条评论 ·
维护者通常 1 天内回复
-
extension-modules type-bug
难度 2/5 1-3 小时 新手友好度 72/100
python/cpython#160001 · 3 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 78/100
glossyio/traffic-monitor#264 ·
维护者通常 1 天内回复
-
Add self-host未关闭
难度 1/5 1 小时以内 新手友好度 75/100
Atarity/deploy-your-own-saas#102 ·
-
[Bug]: RDFlex silently drops the covariate adjustment when the outcome or treatment column is integer-typed可能已有人在做 @vrjdev 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
DoubleML/doubleml-for-py#424 ·
维护者通常 1 天内回复
-
agentic-dmx docs enhancement
难度 1/5 1-3 小时 新手友好度 86/100
-
难度 1/5 1 小时以内 新手友好度 72/100
521xueweihan/HelloGitHub#4150 ·