Summary

Pre-release sweep so every decided 2.0 removal warns in 1.3.0, the bridge release (holding #252 until this lands):

• bytes input (Drop bytes input in 2.0; require str #245): DeprecationWarning with a decode-first hint when bytes reaches HumanName/full_name or SetManager.add()/add_with_encoding(); the encoding kwarg documented as deprecated with it. The other bytes paths already crash or raise, so they need no warning.
• SetManager.__call__ (SetManager inherits an API surface it doesn't want; decide its real interface #243): warns — common to both SetManager inherits an API surface it doesn't want; decide its real interface #243 options, so it doesn't prejudge the A/B decision.
• remove() of a missing member (SetManager inherits an API surface it doesn't want; decide its real interface #243): warns (will raise KeyError in 2.0, matching set.remove) — also common to both options. Adds discard() as the intentional ignore-missing spelling, with the same _on_change cache invalidation; removing present members is unchanged and silent.
• Deliberately not warned: the option-A-only removals (set operators, the Set ABC/isinstance) — SetManager inherits an API surface it doesn't want; decide its real interface #243 is still open for feedback, and warning now would pre-empt it.

Follow-up: stacklevel fix from review

A multi-agent review caught that the bytes-deprecation warnings misattributed their source line whenever they fired through a wrapper call instead of directly:

• SetManager.add(bytes) → delegates to add_with_encoding(), which had a hardcoded stacklevel=2; the warning pointed at nameparser's own loop instead of the caller.
• HumanName(bytes) → the constructor assigns through the full_name setter, which had the same hardcoded stacklevel=2; the warning pointed at nameparser's own __init__ instead of the caller.

Fixed by extracting the shared decode+warn logic into a private helper (_add_normalized / _apply_full_name) that each public entry point (add()/add_with_encoding(), and the setter/__init__) calls directly with its own correct stacklevel. Verified empirically with warnings.catch_warnings(record=True) that both the direct-call and constructor/wrapper paths now attribute to the actual caller's line.

Also from the same review pass:

• Added the missing .. deprecated:: note to add()'s docstring (only add_with_encoding() had one, but add() is the primary entry point and triggers the same warning).
• Tightened a weak pytest.deprecated_call(match="set") assertion to match="raw underlying set" (the old pattern matched incidental occurrences of "set" in the message).
• Added a test for remove()/discard() called with a mix of present and missing members in a single call, confirming the warning and cache invalidation aren't short-circuited.
• Fixed present-tense wording ("is removed in 2.0") in a couple of test comments to match the future-tense wording used everywhere else ("will be removed in 2.0").

Test plan

• TDD: all new tests watched failing first (16 failures) before implementation
• New tests: each warning fires (pytest.deprecated_call), str paths stay silent under simplefilter("error"), discard() ignores missing/normalizes/chains/invalidates the cached union, present-member remove() doesn't warn, mixed present+missing members in one call
• Three pre-existing bytes tests wrapped in deprecated_call(); suite verified noise-free (no warnings summary), including under -W error::DeprecationWarning
• Full suite 1446 passed / 4 skipped / 22 xfailed, mypy clean, ruff clean, Sphinx html + doctest builds clean
• Stacklevel attribution verified empirically for both direct-call and constructor/wrapper paths on the bytes warnings
• docs/customize.rst updated to mention discard(); release log entries added under Breaking Changes & Deprecations

🤖 Generated with Claude Code