Why don't we use `dataclasses.dataclass` or `pydantic` to define pythonic datamodels, instead of the custom `Serializable` ABC?

[kwsp]

Why don't we use dataclasses.dataclass or pydantic to define pythonic datamodels, instead of the custom Serializable ABC?

1. Serializable's definition implies that it's an abstract base class, yet it's not exactly "abstract" and provides the actual implementation of helper methods serialize and deserialize, which makes it a "mix-in" class rather than an ABC.
2. From reading the code, it seems like the functionalities provided by Serializable can be accomplished by the standard library dataclass or (if desiring something more powerful), the pydantic classes.
3. Using the standard library or pydantic would relieve this library from maintaining the serialization and typing infrastructure, and they are also much more battle tested.

Just some thoughts and rambling since the Serializable mechanism doesn't seem to be very robust as I'm getting bugs from k-wave-python
waltsims/k-wave-python#36

[kwsp]

pydantic should be pretty good at handling nested serialization/deserialization https://pydantic-docs.helpmanual.io/usage/exporting_models/

IIRC the standard library dataclass doesn't handle nested deserialization

[waltsims]

Yes thank you for this. Thinking back the nested serialization was the reasons for not using data classes in the first place. A rewrite would make sense.

[kwsp]

I would help when I get some free time. I actually don't know anything about the "Ultrasound File Format" but it looks very interesting. Definitely nice to have a standard for sharing data.