python attrs

I came across a very interesting library in a HN thread: the python attrs library.

In particular, this seems like a great way to do the “dumb data objects” they talk about in the end of object inheritance, and also related to (but maybe lighter weight than) zope.interface.

This also seems very similar to what I use autovalue for at work.

One particularly interesting application is a “code database” – using static, checked-in-to-version-control definitions of some data model as a sort of very-fast-to-read, very-slow-to-update “Data Model”. I find this fascinating: Code shares a lot of properties with great data stores: ability to rollback (git revert) and accountability/auditability (git blame). It also makes a lot of fairly hard problems much simpler: you don’t need to poll the database for changes. You don’t need to invalidate any caches. You don’t need to consider a “split brain” environment where half of the in-memory caches have updated but the other half haven’t. You don’t need to consider failure cases of how long the in-memory cache is allowed to be invalid: you just fail to boot up on deploy. (Admittedly, there’s still an opportunity window for split brain behavior for the duration of the deploy, but this is a lot easier to reason about than an essentially arbitrary.)

Immutable objects also work surprisingly well for interactions with database-backed objects. The notion of “data model dirtiness” (that is, unwritten writes in an ORM framework) correlates very strongly and is relatively easy to observe from the litmus test of whether the data model has round-tripped to and from the mutable representation. Difficulties like “is this timestamp database time or JVM time?” are mostly phased out, because it simply always uses the JVM time – subject to an explicit modeling of constraints of the database (like precision).

Interestingly, jOOQ actually supports an “Immutable Pojo” flag in the codegen phase. In practice, jOOQ’s approach has other difficulties – namely, the lack of index awareness and the inconvenience of the native (read: tightly coupled with your database) objects – but I think this is ultimately a step in the right direction.