nameparser parses human names into seven fields — title, given, middle, family, suffix, nickname, maiden. Results are immutable, configuration is composable, and locale packs are opt-in.
📣 nameparser 2.0 is out. Existing HumanName code keeps working
through 2.x — most 1.x code needs no changes. The migration guide has the
field-by-field map, and anything the migration missed can be reported
on the discussion issue.
pip install nameparser
Requires Python 3.11+.
>>> from nameparser import parse
>>> name = parse("Dr. Juan Q. Xavier de la Vega III")
>>> name.given, name.family
('Juan', 'de la Vega')
>>> name.render("{family}, {given}")
'de la Vega, Juan'Those seven fields are title, given, middle, family,
suffix, nickname, and maiden — plus aggregate views like
given_names, surnames, family_base, and family_particles
for combining or splitting them further.
- Using the parser — the full tour: input shapes, aggregates, rendering, comparison, ambiguities, tokens
- Customizing the parser — vocabulary, behavior, and presentation
- Locale packs — opt-in bundles for East Slavic patronymics, Turkic markers, and more
- There's also a CLI:
python -m nameparser --json "Doe, John"
HumanName and CONSTANTS keep working in 2.0 — same imports, same
attributes, same mutation API. What 2.0 removes is the batch of
deprecations 1.3 and 1.4 announced, so if your test suite runs clean on
1.4 under python -W error::DeprecationWarning, you are nearly done.
Two things that check will not catch: four removals 1.4 never warned
about (three raise on contact, the fourth only warns), and one that
changes results silently — name == "John Smith" is now False.
Migrating from HumanName
covers both, and translates a v1 customization into the new API whenever
that's convenient for you.
See the release log for the full list of changes in the 2.0 series.
LGPL licensed. See LICENSE for details.