Good question! Dataclasses were actually pretty easy - Python's introspection tools made them straightforward.
The tricky parts were:
- Type hints - Mapping __init__ params to attributes, especially with complex types
- Preserving types - Keeping tuples as tuples and sets as sets (not just lists)
- Error messages - Tracking paths like obj.address.street through the whole pipeline
I checked out safeserialize, by the way—the focus on preventing arbitrary code execution is a really smart niche.
Pydantic is great lib and and has many advantages over Jsonic,
I think main use cases for Jsonic over Pydantic are:
- You already have plain Python classes or dataclasses and don’t want to convert them to BaseModel
- You prefer minimal intrusion - no inheritance, no decorators, no schema definitions
- You need to serialize and deserialize Pydantic models alongside non-Pydantic classes
Having said that, Pydantic is the better choice in most cases.
This is also why Jsonic integrate natively with Pydantic so you can serialize Pydantic models using Jsonic out of the box
I built it after repeatedly running into friction with Python’s built-in json module when working with classes, dataclasses, nested objects, and type hints.
Jsonic focuses on:
- Zero-boilerplate serialization and deserialization
- Strict type validation with clear errors
- Natural support for dataclasses, enums, tuples, sets, nested objects etc.
- Optional field exclusion (e.g. hiding sensitive data)
- Extra features like transient fields definition, suport for __slots__ classes etc.
- Clean interop with Pydantic models
The goal is to make JSON round-tripping feel Pythonic and predictable without writing to_dict() / from_dict() everywhere.
I’d really appreciate feedback on the API design and tradeoffs.
Author here. This came from a production incident where renaming a field
broke our rolling deployment. The cache became a shared contract between
versions we hadn't versioned.
The solution: automatically derive version identifiers from model structure
at startup, prefix cache keys with them. Schema changes naturally map to
new cache namespaces.
Happy to discuss tradeoffs or alternative approaches!
The tricky parts were:
- Type hints - Mapping __init__ params to attributes, especially with complex types - Preserving types - Keeping tuples as tuples and sets as sets (not just lists) - Error messages - Tracking paths like obj.address.street through the whole pipeline
I checked out safeserialize, by the way—the focus on preventing arbitrary code execution is a really smart niche.