# PEP 837: Extensible JSON serialization **URL:** \ **Category:** Core Development\ **Tags:** pep\ **Created:** [July 12, 2026, 6:17am UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124 "2026-07-12T06:17:44Z")\ **Posts on this page:** 6\ **Page:** 3
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [July 18, 2026, 4:17pm UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/41 "2026-07-18T16:17:39Z")
I’m not a fan of it being a global state, but I somewhat think copyreg makes more sense for a location for this than most places, including on the class itself (different applications need to serialize types differently, we know this). (Constructing and passing around a serializer/deserializer with the appropriate options seems the _best_ option, but that’s already possible and people don’t always do it when they should) I wonder if the API in copyreg can be imrpoved so that consumers of the api can get a point in time snapshot that can’t change under them, without having to create than snapshot themselves. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [July 20, 2026, 9:47pm UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/42 "2026-07-20T21:47:31Z")
> [@TomRitchford](#): > > That bird flew a long time ago. `numpy` has `numpy. __array__ `, `torch` has several dunderscore methods for derived classes, ujson apparently has one, and other important tools do too. Sure, but the point from Serhiy is that while potential breakage will be taken into consideration, we also don’t have to feel bad if there is some due to people not following this rule. > [@TomRitchford](#): > > With hindsight, perhaps it would have been better to have been stricter about that rule. It would be very hard to implement in a way that’s forwards-compatible. Python is a language of consenting adults, so people should realize what risks they are taking on when doing something. ---
**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\ **Post date:** [July 24, 2026, 5:03am UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/43 "2026-07-24T05:03:46Z")
> [@warden](#): > > That is useful, but it contradicts this sentence in the proposal: > > > […] the hooks are only consulted for objects that would otherwise head toward `default=` or `TypeError`. Thank you, I fixed this little inaccuracy in in the top post (it was not in the PEP). > that would otherwise head toward **the isinstance checks,** `default=` or `TypeError`. ---
**Author:** ![jvdillon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jvdillon/32/38125_2.png) [@jvdillon](https://discuss.python.org/u/jvdillon)\ **Post date:** [October 20, 2026, 9:13pm UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/44 "2026-10-20T21:13:35Z")
Hello! I maintain treekle, which converts arbitrary objects to plain trees and back for json.dumps. We started with exactly that pure-Python pre-pass. On 43 real experiment configs (nested dataclasses), the Python walker was 6.3x slower to encode and 95x slower to decode than the same logic in Rust (4.8 ms vs 0.77 ms; 16.2 ms vs 0.17 ms). [GitHub - rekursiv-ai/treekle: Strongly-typed fast pickler producing plain python trees. · GitHub](https://github.com/rekursiv-ai/treekle#speed) A wrapper works, but each one walks the tree a second time in Python, and that walk dominates the cost. Hooks inside the C encoder avoid it. Msgspec follows suit but defined their own container to speed it up whereas we opted to support native python. Question on “Neutral ground”: is the intent that third-party native encoders read copyreg.json\_dispatch\_table directly? Benchmark: > ---
**Author:** ![bwoodsend](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bwoodsend/32/4027_2.png) [@bwoodsend](https://discuss.python.org/u/bwoodsend)\ **Post date:** [October 21, 2026, 12:34am UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/45 "2026-10-21T00:34:01Z")
To be clear, when I said wrapper function, I just meant something like: ```python def json_dumps(*args, **kwargs): return json.dumps(*args, **kwargs, dispatch_table={decimal.Decimal: str}, default=json_default) ``` Not walk the entire structure (although I suppose that’s also an option – and one that works with any JSON library). ---
**Author:** ![jvdillon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jvdillon/32/38125_2.png) [@jvdillon](https://discuss.python.org/u/jvdillon)\ **Post date:** [October 23, 2026, 9:43pm UTC](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124/46 "2026-10-23T21:43:45Z")
I see your point; probably my point was just noise then. I did want to raise however that the walking is the hard/slow part. But regardless, I definitely agree we should have an agnostic ` __serialize__ ` and this was what I optimized for in treekle. In fact, this is why its “tree”+“pickle” not “json pickle”–I felt going to plain python tree is better because then last mile serialization can be handled elsewhere. There is a caveat though. Converting object to tree and tree to JSON can be made 2x faster if you go directly to JSON so there is a tension between agnosticism and performance. [Previous page](https://discuss.python.org/t/pep-837-extensible-json-serialization/108124.md?page=2)