You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
regexes.no_vowels is dead config — deprecate and remove in 2.0 #268
REGEXES["no_vowels"] (^[^aeyiuo]+$, nameparser/config/regexes.py) is not referenced anywhere in the parser or the documentation sources. It was added in 4a6aa61 (Aug 2015) and appears never to have been used.
Beyond being dead weight, the pattern is misleading as public config: it's ASCII-only, so every non-Latin string ("Петров", "山田") matches "no vowels" — anyone reaching for it for its apparent purpose (detecting vowel-less abbreviations like "Dr") gets false positives on all non-Latin text.
Since C.regexes.no_vowels is technically public API surface, removal is a breaking change. Proposal: deprecate in a 1.x release (following the established 2.0 deprecation-warnings pattern from #253) and remove in 2.0.
Shipped in the 2.0 branch and included in 2.0.0rc2 — regexes.no_vowels is removed; access now fails with an AttributeError naming the miss (the #256 behavior), and the removal is release-log-documented.
Closing note: this issue's original plan was a 1.x deprecation first, and 1.4 shipped without one — closing as-is anyway. The pattern was dead config the parser never read, so there was no behavior to warn about, and the 2.0 failure mode is loud and self-explaining rather than silent.
Activity
Remove the dead regexes.no_vowels config (#268)
docs: rewrite the 2.0 release log new-API-first and complete the audit
Pin the four hand-copied patterns the sync roster never listed
derek73 commentedon Jul 28, 2026
Shipped in the 2.0 branch and included in 2.0.0rc2 —
regexes.no_vowelsis removed; access now fails with anAttributeErrornaming the miss (the #256 behavior), and the removal is release-log-documented.Closing note: this issue's original plan was a 1.x deprecation first, and 1.4 shipped without one — closing as-is anyway. The pattern was dead config the parser never read, so there was no behavior to warn about, and the 2.0 failure mode is loud and self-explaining rather than silent.