You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A default HumanName shares the module-level CONSTANTS singleton as its .C. pickle and copy.deepcopy cannot preserve object identity, so after a
round-trip .C is a detached copy rather than the singleton. This flips has_own_config from False to True and bloats every serialized default name
with a full Constants copy (~1000+ entries).
Surfaced during the round-trip work in #168 (which fixes the value-level
round-trip bugs but deliberately leaves this identity/semantic issue out of
scope).
(self.C is never legitimately None — the constructor replaces None with a
fresh Constants — so None is a safe sentinel. Confirm before relying on it.)
Notes / things to decide
This changes HumanName serialization semantics, so it warrants its own PR and
a changelog note.
Needs tests: default name round-trips with .C is CONSTANTS and has_own_config == False; an instance-config name still round-trips its own
config (covered today by the tests added in Fix pickle/copy round-trip bugs in Constants and config managers #168); both pickle and copy.deepcopy.
Decide whether copy.copy (shallow) behavior should match.
Activity
fix: restore CONSTANTS singleton identity across pickle/deepcopy (closes