In 2.0, HumanName is reimplemented as a compatibility facade over the new parsing core: the facade delegates parsing to the core engine rather than calling its own (former) parsing methods. A subclass that overrides a parsing hook — parse_full_name, parse_pieces, join_on_conjunctions, pre_process, post_process, or the is_* predicates (is_title, is_prefix, is_suffix, is_conjunction, …) — will still construct and parse without error, but the override is never called.
This is the only planned v1→v2 change that fails silently: every other removal raises or warns, but here the subclass just quietly parses differently. Subclass-override users exist in the wild — the 1.3.0 release note for the __process_initial__ → _process_initial rename assumes exactly this audience.
2.0: at HumanName.__init__, compare the known hook attributes on type(self) against HumanName's own (type(self).parse_pieces is not HumanName.parse_pieces, etc.) and emit a DeprecationWarning — once per subclass, not per instance — naming the overridden methods and stating they will not be called. DeprecationWarning rather than RuntimeWarning: this is a migration matter, not a runtime hazard, and the fix is migrating the customization to the new API (or requesting the missing switch as a feature).
No 1.4 bridge warning for this one, deliberately: the only actionable response to the warning is migrating to the new API, which doesn't exist until 2.0 — a 1.4 warning would be noise its audience cannot act on. (Same fairness rule that keeps the shared-CONSTANTS deprecation in 2.0.)
In 2.0,
HumanNameis reimplemented as a compatibility facade over the new parsing core: the facade delegates parsing to the core engine rather than calling its own (former) parsing methods. A subclass that overrides a parsing hook —parse_full_name,parse_pieces,join_on_conjunctions,pre_process,post_process, or theis_*predicates (is_title,is_prefix,is_suffix,is_conjunction, …) — will still construct and parse without error, but the override is never called.This is the only planned v1→v2 change that fails silently: every other removal raises or warns, but here the subclass just quietly parses differently. Subclass-override users exist in the wild — the 1.3.0 release note for the
__process_initial__→_process_initialrename assumes exactly this audience.2.0: at
HumanName.__init__, compare the known hook attributes ontype(self)againstHumanName's own (type(self).parse_pieces is not HumanName.parse_pieces, etc.) and emit aDeprecationWarning— once per subclass, not per instance — naming the overridden methods and stating they will not be called.DeprecationWarningrather thanRuntimeWarning: this is a migration matter, not a runtime hazard, and the fix is migrating the customization to the new API (or requesting the missing switch as a feature).No 1.4 bridge warning for this one, deliberately: the only actionable response to the warning is migrating to the new API, which doesn't exist until 2.0 — a 1.4 warning would be noise its audience cannot act on. (Same fairness rule that keeps the shared-
CONSTANTSdeprecation in 2.0.)