test_str: the UCS4 adaptive search path is never exercised
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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分
- マージ済み PR（30日）
- 708
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 が 1 日前に担当しました。 オープン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
-
backlog
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
EchoTools/nevr-runtime#1108 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
btclib-org/btclib-wallet#587 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Judgment-Pack/judgment-pack-spec#275 ·
メンテナーはふだん 1 日以内に返信