nameparser 2.0 — a new immutable core API, with full compatibility for existing code through 2.x.
parse() returns an immutable ParsedName whose seven fields are named for what they are (given, family) rather than where they sit in a Western name, configured by two frozen value objects — a Lexicon of vocabulary and a Policy of behavior — instead of a mutable global. Every parse can tell you what it had to guess at (ambiguities) and exactly where each token came from (tokens, with character spans).
HumanName keeps working. It is now a compatibility facade over the same pipeline and stays through 2.x — most 1.x code needs no changes. What 2.0 removes is the batch of deprecations announced in 1.3 and 1.4; if your suite runs clean on 1.4 under python -W error::DeprecationWarning, you are nearly done. One removal changes results silently rather than raising: name == "John Smith" is now False — use matches(). The migration guide has the field-by-field map.
Highlights:
- Seven named fields —
title,given,middle,family,suffix,nickname,maiden— plus derived views (family_particles,given_names, …),render(spec),initials(),capitalized(), and semantic comparison viamatches()/comparison_key() - Composable configuration — frozen
Lexicon+Policy, partialPolicyPatchdeltas,Policy.patched(), andParser.revise()for tag-preserving corrections - Family-first name order (
Policy(name_order=FAMILY_FIRST)) and opt-in locale packs (parser_for(locales.RU)) — never auto-detected - Non-Latin vocabulary in the default lexicon (Cyrillic, Greek, Arabic, Hebrew), typographic nickname delimiters, and maiden-name markers (
née,geb., …) - Python 3.11+, zero runtime dependencies, fully typed (PEP 561)
The full change list is in the release log; rc1/rc2 testers can read its "Changed since 2.0.0rc1" section. Please report anything the migration missed on #284.
🤖 Generated with Claude Code