René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"nameparser 2.0: a new core API, with full compatibility through 2.x — direction and feedback","articleBody":"nameparser 2.0 is in design. This issue is the front door: the short version, links to the full design, and the specific feedback that would help most. There is no deadline — comment whenever; implementation will proceed in parallel and alphas will be announced here.\n\n## The promise\n\n**Code that runs warning-free on 1.4 keeps running on every 2.x release with identical results**, getting at most `DeprecationWarning`s. `HumanName` continues to work as a compatibility layer. The old API is removed in 3.0, not 2.x, and only after every removal has warned first. If you use `HumanName` and don't customize configuration, 2.0 should be a non-event.\n\n## What's new\n\nA second, immutable API alongside `HumanName`:\n\n```python\nfrom nameparser import parse\n\nname = parse(\"Dr. Juan Q. Xavier de la Vega III\")\nname.given         # \"Juan\"      (the new API says given/family, not first/last)\nname.family        # \"de la Vega\"\nname.family_base   # \"Vega\"\n```\n\n- `parse()` returns a frozen value object; no mutable state anywhere in the new API\n- configuration becomes immutable `Lexicon` (vocabulary) + `Policy` (behavior) objects you build at startup — no more mutating shared `CONSTANTS` (which keeps working through 2.x, with a warning)\n- family-first name order (`Policy(name_order=FAMILY_FIRST)`) and opt-in locale packs (`RU`, `TR_AZ` at 2.0.0; zh/ko/vi/ja staged)\n- genuinely ambiguous parses are *reported* (`name.ambiguities`) instead of silently guessed\n- still deterministic, rules-based, zero dependencies; Python ≥ 3.11\n\n## Read and comment\n\n- **The full RFC: #285** — line comments welcome there; it covers the API, migration mechanics, timeline, and rejected alternatives\n- **[Milestone v2.0](https://github.com/derek73/python-nameparser/milestone/35)** — the tracked removals and changes\n\n## Feedback that would help most\n\n1. Do you compare `HumanName` objects with `==` (especially against strings), or use them in sets/dicts? (2.0 changes this to object identity — warned since 1.3.0; `matches()`/`comparison_key()` are the replacements. The one silent behavior change.)\n2. Do you subclass `HumanName` and override parsing methods? Tell us what the override does — we'd rather absorb it as a feature than break it silently (#280).\n3. Do you mutate `CONSTANTS` after startup, not just at import time?\n4. Do you assign custom regexes to `CONSTANTS.regexes`? What for?\n5. `given`/`family` instead of `first`/`last` in the new API — help or annoy?\n6. Do you build anything on top of nameparser where the promise above would still break you?\n","author":{"url":"https://github.com/derek73","@type":"Person","name":"derek73"},"datePublished":"2026-07-12T03:47:24.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/284/python-nameparser/issues/284"}