4 ms·

I've recently been using attrs as an easy way to make simple datatypes, but its only gesture towards validation is an arbitrary callback per field. Hooking into

I've recently been using attrs as an easy way to make simple datatypes, but its only gesture towards validation is an arbitrary callback per field. Hooking into Python 3 type annotations is a great idea! Does/will Pydantic handle all the standard dunder fields like __eq__, __lt__, __hash__, __cmp__ and faux-immutability like namedtuple and attrs do?

noisy_boy 9y ago
Do you have a writeup/blog post on your approach? I would like to read more about it.
- thristian 9y ago
  In the small, it's just using attrs the way it's described in its documentation. 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.
- scolvin 9y ago
  I don't. I'm not sure it would be that interesting. 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/aiohttp_devtools/start/template/app/settings.py#L48 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.
scolvin 9y ago
"faux-immutability" is a good way to describe it. My problem is the "faux"; proper immutability is virtually impossible in python and I'm not convinced about providing partial immutability and thereby giving people a false sense of security. That said there's an issue about it: https://github.com/samuelcolvin/pydantic/issues/38 https://github.com/samuelcolvin/pydantic/issues/38. I'll consider it if we can find a performant and elegant way of using it. __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.

noisy_boy 9y ago

Do you have a writeup/blog post on your approach? I would like to read more about it.

thristian 9y ago
In the small, it's just using attrs the way it's described in its documentation. 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.
scolvin 9y ago
I don't. I'm not sure it would be that interesting. 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/aiohttp_devtools/start/template/app/settings.py#L48 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.

scolvin 9y ago

"faux-immutability" is a good way to describe it. My problem is the "faux"; proper immutability is virtually impossible in python and I'm not convinced about providing partial immutability and thereby giving people a false sense of security. That said there's an issue about it: https://github.com/samuelcolvin/pydantic/issues/38 https://github.com/samuelcolvin/pydantic/issues/38. I'll consider it if we can find a performant and elegant way of using it. __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.