Repository navigation
Housekeeping left over from the #293 vocabulary rename #356
Description
Minor findings from PR #354's review, deferred so that PR stayed reviewable. None affects behaviour.
Bridge / API surface
nameparser/config/particles.pyandbound_given_names.pyhave no__all__, sofrom ... import *leaksassert_normalized, andparticles.pyre-exportsBOUND_GIVEN_NAMES(which belongs to the other module and is imported only for its disjointness assert). Their 1.x predecessors gained__all__in Rename the vocabulary data modules to the 2.0 terminology, with a 2.x bridge (#293) #354; the migration destinations did not.__dir__raisesKeyErrorrather thanAttributeErrorif the module has been dropped fromsys.modules. Off the read path — only an explicitdir()reaches it.inspect.getmembers()/help()ontitles/suffixesresolves the retired names and emits theirDeprecationWarnings.
Tests
_RETIRED_NAMESintests/v2/test_config_aliases.pyis fully derivable fromALIASES(verified identical). A second hand-written copy of the same five names in the same file is drift surface: a sixth alias added to one and not the other silently exempts that name from the internal-usage scan.ALIASESis a bare 4-tuple indexed positionally in six places (for m, n, _, _ in ALIASES)._LatinCopyintests/v2/test_ledger_guards.pyis the suite's ownNamedTupleprecedent.test_star_import_binds_exactly_the_live_and_retired_namesasserts names but never values, so an__all__entry routed to the wrong constant is caught only incidentally.from X import Ywarning attribution is tested for one alias of five. The two same-module aliases are a structurally different shape (the table sits at the bottom of a module that is mid-execution during import).
Docs
docs/customize.rstsays "TITLES,PARTICLESand the rest ofnameparser.config" are frozen —CAPITALIZATION_EXCEPTIONSandREGEXESare still dicts — and its next sentence reads as thoughTITLESwas renamed, which it wasn't.AGENTS.md:208keeps "first-name join"/"last-name join" on a line whose constants were renamed to the given/family vocabulary.AGENTS.md:240saysSUFFIX_ACRONYMS − {esq}"changes many"; measured, only the multi-dot spellings change. The paragraph's refusal to publish a count is right — "changes the multi-dot spellings" is both truer and count-free.AGENTS.md:254'snickname_delimitersstring-sentinel gotcha is stale for 2.x:CONSTANTS.regexes.parenthesis = ...raisesTypeError, and delimiters reach the parse asPolicypairs. It sits in a section not marked as v1 history.nameparser/config/__init__.pycites the migration spec's §3 for a list that lives in §4, and both citations point into gitignoreddocs/superpowers/, so nobody without that directory can check either.
Found by the five-agent review on PR #354 (comment accuracy, test coverage, silent failures, type design, general code review).
Added after the 2.2 bridge changed semantics
-
AGENTS.md:224still explains the internal-usage guard by saying an internal read "would also consume the once-per-process warning and leave the real caller told nothing." That stopped being true when the bridge moved to per-read-location warnings. Measured on master:internal_reader.py:1 then real_caller.py:1 -> 2 warningsThe guard is still worth keeping — an internal read emits a warning attributed to library code the caller cannot act on, and breaks their
-W error::DeprecationWarningruns — but the stated reason is wrong.docs/release_log.rst:48states the new semantics correctly, so this is the only stale site.
Activity
Point SUFFIX_ACRONYMS_AMBIGUOUS at the readers it has
Split the delimiter gotcha into what 2.0 kept and what it deleted
docs(release_log): say what the release is, plainly
Merge pull request #477 from derek73/claude/v2-2-0-release-finalizati…
chore(config,tests): the derek73#293 rename housekeeping deferred out…