Five places describe leading-particle behaviour in terms of which field the piece ends up in. Each is true under the default GIVEN_FIRST and falsified by Policy(name_order=FAMILY_FIRST), which shipped in 2.1:
de la Vega default: family='de la Vega' FAMILY_FIRST: family='de', given='la Vega'
Van Johnson default: given='Van' FAMILY_FIRST: family='Van', given='Johnson'
de Mesnil default: family='de Mesnil' FAMILY_FIRST: family='de', given='Mesnil'
The underlying rule is a grouping-stage one that runs before roles are assigned and never consults policy.name_order, so the mechanism claims are all fine — only the field destinations need scoping.
Sites
nameparser/_lexicon.py:335-337 — the particles_ambiguous field docstring ("a leading one reads as given")nameparser/_types.py:359 — PARTICLE_OR_GIVENdocs/usage.rst:120-130docs/concepts.rst:161-164docs/customize.rst:170-181 — "a name starting with it has no given name at all"
Why these five and not the two already fixed
PR #354 corrected the two instances it had itself written (nameparser/config/particles.py and AGENTS.md:136) and deliberately left these. Fixing one of five would be arbitrary, and they want a single sweep in consistent wording.
The pattern to follow is the one #354 landed: lead with the mechanism, then show where the piece lands under the default order, making the order-dependence explicit rather than implied.
Verify every claim against a real parse before rewriting it. #354's review found six docstring claims that were plausible and false — including two written to replace other false claims.
Five places describe leading-particle behaviour in terms of which field the piece ends up in. Each is true under the default
GIVEN_FIRSTand falsified byPolicy(name_order=FAMILY_FIRST), which shipped in 2.1:The underlying rule is a grouping-stage one that runs before roles are assigned and never consults
policy.name_order, so the mechanism claims are all fine — only the field destinations need scoping.Sites
nameparser/_lexicon.py:335-337— theparticles_ambiguousfield docstring ("a leading one reads as given")nameparser/_types.py:359—PARTICLE_OR_GIVENdocs/usage.rst:120-130docs/concepts.rst:161-164docs/customize.rst:170-181— "a name starting with it has no given name at all"Why these five and not the two already fixed
PR #354 corrected the two instances it had itself written (
nameparser/config/particles.pyandAGENTS.md:136) and deliberately left these. Fixing one of five would be arbitrary, and they want a single sweep in consistent wording.The pattern to follow is the one #354 landed: lead with the mechanism, then show where the piece lands under the default order, making the order-dependence explicit rather than implied.
Verify every claim against a real parse before rewriting it. #354's review found six docstring claims that were plausible and false — including two written to replace other false claims.