I must admit, I chose the title of this submission poorly. It should have read "stop passing naked dictionaries around for everything". Of course, dictionaries

I must admit, I chose the title of this submission poorly. It should have read "stop passing naked dictionaries around for everything". Of course, dictionaries are incredibly useful when called for (for instance, when you want to iterate over the keys!). But I have frequently seen them being used when class instances would be better suited. Dictionaries' values cannot be replaced with methods via @property, and as a result, I've found they often need to be replaced with objects at some point. DStruct is a response to that problem where your access interfaces aren't forwards-compatible with the great majority of types you might choose in the future (ORM/ODM instances are a big one). But I've also found it quite useful in the other direction: when replacing what was once an ORM/ODM class with something mocked (e.g. the data source that was once a database has become a remote resource, local file, parser output, or configuration dict), having to run around changing attribute accessors to dict accessors is a drag at best, and impossible at worst (e.g. If you were using @property extensively to return computed attributes, or you know at hydration time that code elsewhere relies on a schema (I do both a times, as anyone writing large, maintainable applications should.). As another commenter also mentioned, my approach does yield prettier code. While it's not always sufficient cause, prettier code is in fact a good thing.