#293 renamed the nameparser/config vocabulary to the 2.0 terminology in 2.2 and kept every 1.x name resolving through a DeprecationWarning bridge. The warning names 3.0 as the removal, so this is that commitment coming due.
What to delete
Verified against master at 5331b5a.
Whole files — these exist only to serve the bridge:
nameparser/config/_deprecated.py (133 lines) — the alias_getattr factory
nameparser/config/prefixes.py (38 lines) — shim, no data
nameparser/config/bound_first_names.py (23 lines) — shim, no data
tests/v2/test_config_aliases.py (327 lines) — the bridge's entire test surface
In-module blocks, both at the end of the file after the import-time asserts:
nameparser/config/titles.py — the TYPE_CHECKING/alias_getattr pair, and FIRST_NAME_TITLES from __all__
nameparser/config/suffixes.py — the same pair, and SUFFIX_NOT_ACRONYMS from __all__
Both __all__ lists themselves stay: they are load-bearing for autodoc_member_order = 'bysource' and must remain in source order. Removing only the TYPE_CHECKING branch and leaving the retired name in __all__ is a ruff F822 error rather than a silent one, so the tree will tell you if you do half the job.
Prose:
docs/migrate.rst — the bridge table and the section around it (~lines 236-260), plus the flip-warning reference at ~411
AGENTS.md:224 — the retired-name half of the frozen-constants gotcha; the freeze half stays
- Leave
docs/release_log.rst alone entirely. Its 2.2 entry is the historical record of what shipped.
Decide first: where the vocabulary lives in 3.0
The migration spec says 3.0 removes nameparser.config "in its entirety" while its parenthetical enumerates only the five v1 shim names (Constants, CONSTANTS, SetManager, TupleManager, RegexTupleManager). Those disagree, and #293 gave the disagreement a cost: Lexicon's public field docstrings now cross-reference nameparser.config.particles by path, and docs/modules.rst autodocs the config package. If 3.0 moves the vocabulary under the core (say nameparser/_vocabulary/), roughly nine :data: references and a docs section move with it — and the module name #293 established changes address one version later.
Settle that before the sweep rather than during it. The answer decides whether this issue is "delete a bridge" or "delete a bridge and relocate the vocabulary".
If it does move, note what #293 learned the hard way: git records no renames, it infers them at diff time by pairing a deleted path with an added one, so the move must be its own commit with nothing re-created at the old path, or git blame on the vocabulary restarts at the move. See PR #354's e4f8385/9956e7d split.
Acceptance
grep -rn "PREFIXES\|NON_FIRST_NAME_PREFIXES\|BOUND_FIRST_NAMES\|FIRST_NAME_TITLES\|SUFFIX_NOT_ACRONYMS" nameparser/ docs/ AGENTS.md returns hits only in docs/release_log.rst
from nameparser.config.prefixes import PREFIXES raises ModuleNotFoundError
from nameparser.config.titles import FIRST_NAME_TITLES raises ImportError
- no
DeprecationWarning remains anywhere in nameparser/config/
- suite, mypy, ruff and the sphinx build green with the four files gone
#293 renamed the
nameparser/configvocabulary to the 2.0 terminology in 2.2 and kept every 1.x name resolving through aDeprecationWarningbridge. The warning names 3.0 as the removal, so this is that commitment coming due.What to delete
Verified against master at
5331b5a.Whole files — these exist only to serve the bridge:
nameparser/config/_deprecated.py(133 lines) — thealias_getattrfactorynameparser/config/prefixes.py(38 lines) — shim, no datanameparser/config/bound_first_names.py(23 lines) — shim, no datatests/v2/test_config_aliases.py(327 lines) — the bridge's entire test surfaceIn-module blocks, both at the end of the file after the import-time asserts:
nameparser/config/titles.py— theTYPE_CHECKING/alias_getattrpair, andFIRST_NAME_TITLESfrom__all__nameparser/config/suffixes.py— the same pair, andSUFFIX_NOT_ACRONYMSfrom__all__Both
__all__lists themselves stay: they are load-bearing forautodoc_member_order = 'bysource'and must remain in source order. Removing only theTYPE_CHECKINGbranch and leaving the retired name in__all__is a ruffF822error rather than a silent one, so the tree will tell you if you do half the job.Prose:
docs/migrate.rst— the bridge table and the section around it (~lines 236-260), plus the flip-warning reference at ~411AGENTS.md:224— the retired-name half of the frozen-constants gotcha; the freeze half staysdocs/release_log.rstalone entirely. Its 2.2 entry is the historical record of what shipped.Decide first: where the vocabulary lives in 3.0
The migration spec says 3.0 removes
nameparser.config"in its entirety" while its parenthetical enumerates only the five v1 shim names (Constants,CONSTANTS,SetManager,TupleManager,RegexTupleManager). Those disagree, and #293 gave the disagreement a cost:Lexicon's public field docstrings now cross-referencenameparser.config.particlesby path, anddocs/modules.rstautodocs the config package. If 3.0 moves the vocabulary under the core (saynameparser/_vocabulary/), roughly nine:data:references and a docs section move with it — and the module name #293 established changes address one version later.Settle that before the sweep rather than during it. The answer decides whether this issue is "delete a bridge" or "delete a bridge and relocate the vocabulary".
If it does move, note what #293 learned the hard way: git records no renames, it infers them at diff time by pairing a deleted path with an added one, so the move must be its own commit with nothing re-created at the old path, or
git blameon the vocabulary restarts at the move. See PR #354'se4f8385/9956e7dsplit.Acceptance
grep -rn "PREFIXES\|NON_FIRST_NAME_PREFIXES\|BOUND_FIRST_NAMES\|FIRST_NAME_TITLES\|SUFFIX_NOT_ACRONYMS" nameparser/ docs/ AGENTS.mdreturns hits only indocs/release_log.rstfrom nameparser.config.prefixes import PREFIXESraisesModuleNotFoundErrorfrom nameparser.config.titles import FIRST_NAME_TITLESraisesImportErrorDeprecationWarningremains anywhere innameparser/config/