Let the glued-honorific peel cross a comma and a 间隔号 (#312)

[derek73]

Summary

#308's glued-honorific peel sat behind two gates it never asked for — the family comma and the 间隔号 — inherited purely from where it was placed in script_segment. Both gates answer where does a name divide into surname and given. The peel asks something else: does this token end in a word that can never end a name? A comma or a dot elsewhere in the string does not change that answer.

This moves the peel in front of both, and changes its site from segments[0] to the name-bearing runs, so it reaches the given-name side of a family comma:

input	before	after
김, 민준씨	given 민준씨	family 김, given 민준, suffix 씨
田中, 太郎さん	given 太郎さん	family 田中, given 太郎, suffix さん
田中さん, PhD	family 田中さん	family 田中, suffix さん, title PhD
威廉·莎士比亚さん	family 莎士比亚さん	family 莎士比亚, suffix さん
田中さん, 太郎	family 田中さん	unchanged

Each now agrees with its spaced spelling. The surname split still stands down for both marks, unchanged — a comma still means the writer said where the family name ends, and the 间隔号 still marks a transcription. Default-on, reaches HumanName.

The stage is also split into two siblings (_peel_honorific_tail, _split_surname_site) with their own gates, so "these answer different questions" is visible in the code rather than only in prose. That is commit 1, deliberately behavior-free, so commit 2 is only the behavior.

The issue was filed with a wrong example

#312 named 田中さん 太郎 vs 田中さん, 太郎 as the motivating pair. They agree — neither peels, because the site is the last non-post-nominal token, which is 太郎 in the spaced form. The real disagreements were mostly on the other side of the comma, where the honorific is glued to the given name.

That matters because the fix the issue proposed — move the peel above the gates, change nothing else — fixes one case of four, misses two, and makes 田中さん, 太郎 peel, introducing a disagreement where none existed. The last row of the table above is pinned precisely because a naive fix breaks it. Issue body and comments corrected.

A regression caught in review

The first draft flattened all segments. segment() admits a post-comma run on is_suffix_lenient while the peel filters with is_suffix_strict, and the initial-shaped suffix words fall in that gap — V., V, I are lenient-True and strict-False. So:

Dr 김민준씨, V.        peel abandoned, 씨 stranded in the given name
Dr 김민준씨, Jr., 박씨  씨 peeled off the junk tail; the person's own stayed glued

Scoping to segments[:2] under a family comma and segments[0] otherwise fixes both — a FAMILY_COMMA name can never span three runs. Now pinned at stage level and by a case row (ko_honorific_glued_given_suffix_comma_initial), the latter added only after simulating the broken scan against the whole case table to confirm no existing row caught it.

Known limit

A doubled comma (김,, 민준씨) does not peel — segment() puts 민준씨 in a suffix run, so it was never name text. Unchanged from before, and the docs are phrased to stay true of it.

Test Plan

• uv run --extra ja pytest -q — 2872 passed, 16 skipped, 11 xfailed
• uv run mypy — clean, 96 files
• uv run ruff check nameparser/ tests/ — clean
• sphinx-build -b html / -b doctest / python -m doctest README.rst — clean, 0 doctest failures
• tools/differential/compare.py vs 1.4.0 — 734 names, 90 intentional, 0 unexplained; each new corpus row's classifying rule verified rather than assumed
• All 8 acceptance criteria measured, including the two regression guards (Dr 김민준씨, Jr. and 김민준씨 (Jimmy) byte-identical)

Closes #312.

🤖 Generated with Claude Code

---

Known limit, recorded not fixed

The peel reaches the first two runs under a family comma and nothing beyond. One fact, several faces — all measured, all byte-identical to pre-#312 and to 1.4.0, so none is a regression:

김, 민준 지훈씨   → suffix 씨       peels (two runs)
김, 민준, 지훈씨  → suffix 지훈씨   does not (third run)
김,, 민준씨      → suffix 민준씨   does not (doubled comma → later run)
田中さん, V.     → family 田中さん  does not (suffixy second run — #319)

田中さん, V. is the interesting one and has its own issue: #319. It needs segment()'s suffixy closure extracted into a shared predicate, which is out of scope here — the cheap substitute was measured and leaves PhD and Ph. D. inconsistent instead. Pinned as a parity case row so the limit is recorded rather than latent.

Note for bisecting

Commit 2 (c89536b, the behavior change) is red on its own: it invalidates ja_honorific_glued_family_comma's expectation, and that row is not updated until commit 3 (b54f692). Every other commit is independently green. This was a deliberate choice in the implementation plan — behavior in one commit, its pins in the next — and is left as-is rather than rewriting pushed history. A git bisect for a CJK-comma regression will stop there with two known failures; they are the row and its facade twin, nothing else.

Whole-branch review

All seven original commits had per-task review; a three-agent whole-branch pass then found what slice-level review structurally could not:

• A coverage hole in the branch's own stated hazard. Every pinned FAMILY_COMMA input had exactly two segments, so segments[:2] was only ever exercised as "more than one run", never as "and not three". A segments[:3] mutant survived the whole suite; its catching input 김, 민준씨, 박씨 peels the junk tail's 씨 and strands the person's own — verbatim the failure the code comment argues against. Now pinned, along with four sibling mutants (extracted content, interpunct-plus-comma, empty leading run, len(segments) == 2).
• Two measured-false code comments, including a third wrong claim about period_joined_vocab — it does classify Smith.Jr. as a title, and parse("Smith.Jr. Anderson") swallows the surname.
• Two universal negatives in the docs with counterexamples, replaced by the scoped statement above.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (6fd116e) to head (3c27dad).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #318   +/-   ##
=======================================
  Coverage   98.46%   98.46%           
=======================================
  Files          41       41           
  Lines        2803     2807    +4     
=======================================
+ Hits         2760     2764    +4     
  Misses         43       43           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.