Does/will Pydantic handle all the standard dunder fields like __eq__, __lt__, __hash__, __cmp__ and faux-immutability like namedtuple and attrs do?
__eq__ makes sense, I'll do it when I get round to it
__hash__ would be nice but far from simple to do in a performant way.
__lt__ I'm not sure what this would mean?
__cmp__ no longer exists in python 3.
In the large, I've been learning about Rust recently and wrapping my head around the design-patterns of static typing. For internal data-structures the benefit is not as clear, but for serialising and deserialising external data (like from config files or JSON APIs) I really prefer having specific, named types instead of a generic bucket of dicts.
API documentation can be more concise. You can say "this argument must be an instance of BuildArtifact" rather than "this argument must be a dict with an 'href' key whose value is the URL to a build artifact and a 'hash' key whose value is the SHA256 of that artifact" in every relevant API.
Debugging is easier when inspecting a variable starts with "<BuildArtifact ...>" rather than just dumping a dict at you.
If you need to operate on a particular kind of data, a named class gives you an obvious place to hang a method, instead of having a loose function rattling about. For operations between two data-types (like 'merge' or 'intersection'), a loose function might still be the most appropriate, but operations like searching or summarizing are naturally methods.
In short:
* I started out with a class that substituted environment variables into itself for settings, still in aiohttp-devtools: https://github.com/aio-libs/aiohttp-devtools/blob/master/aio...
* using annotations occurred to me
* it worked
* it was 50% faster than trafaret which I'd been using before
* I added some unit tests, published to pypi and started using it.