If I'm dealing with dictionaries everywhere, should I make them "classes"?

Question

Right now, I have many python files. Each has many functions.

I'm passing hash maps around everywhere. Basic dictionaries, with a word as a key and a score as the value.

{ 'dog': 33, 'cat': 294 }

I'm also doing some more complicated strcutures, like:

{ 'dog': [ 33, 66, 11, 88 ], 'cat': [11, 66, 22] }

Do I need to turn these into my own "objects"? if so, what would they be? I don't do OOP very much so I'm asking these noob questions.

Answer 1

Having maintained a large codebase for many years that favored raw dicts over objects, my opinion is that if this codebase is going to be maintained by either A) another person or B) several people, you should start migrating toward real classes and OOP. Primarily, the fact that you can easily see what attributes a class instance is supposed to have by looking at the source or even interactively using dir() and other introspection techniques makes your code a lot easier to learn, modify, and maintain. Comprehension and debugging are just that much easier with classes that have intuitive names, well-defined properties, documentation, and readable source code as opposed to a giant mess of functions that take dicts as arguments, and transform them at runtime in myriad ways that can only be understood by reading the entire codebase. Tracebacks are also generally easier to read and decipher when classe are involved since you don't get generic low-level error messages.

As further evidence, go look at mature and successful python projects. You'll see lots of OOP, classes, and documentation. Raw dicts, lists, sets, and tuples are great when appropriate (your data is truly simple) and for small projects and scripts, but the maintainability doesn't last past a certain project size. The notion of "X is just a dict" only survives while your concept of X is extremely simple.