Although I coincidentally mostly agree with the conclusion "encode on entry and decode on exit" I disagree substantially with the rest of the article. > I know

Although I coincidentally mostly agree with the conclusion "encode on entry and decode on exit" I disagree substantially with the rest of the article. > I know that it's now en vogue to sneer at OO I don't sneer at it. OO has been the dominant coding religion for most of my career and I rage against the educators and propagandists who spend a decade smothering everyone with it. I curse them for all the time I wasted trying to build classes for my data only to realize that if I had used a simple dictionary or list my code would be shorter, simpler, more robust, and more flexible. The logic in the article above is all premised on object-oriented religion. OO for OO's sake because OO. Using the power of dictionaries is bad, using the power of objects is good. > It completely defeats object orientation. You could just as easily say using objects defeats the point of having lists and dicts. > It offers nothing of the abstraction powers of object orientation. Most of the abstraction power of object orientation happens when you create the methods. If you aren't defining new classes, you write functions instead. You still have abstractions, what you don't have is the encapsulation of code with data. > It doesn't say what it's doing. Sure it does, and better yet since you are using the standard data types it will be said in a language that any other Python developer is likely understand immediately. > The above code is filled with auxiliary logic that has nothing to do with what it actually tries to achieve. The above code is filled with auxiliary logic because the author of it apparently didn't write any useful functions for operating on dictionaries. I'm not sure that any of the auxiliary logic in that code has anything to do with the choice to use dictionaries. It's a standard data munging problem that comes from having data from different sources. You have the exact same problem with objects if you didn't write any useful methods for operating on them. > but done right, it can be very powerful, especially in big and complex codebases. And in my opinion, the right way to do Object-Orientation in Python is to not do it until you really know you need it: your code is heading towards big and complex and you need to lock it down and organize the data and methods into well-encapsulated classes. (Although maybe at that point you realize it's not a big deal and don't bother) Designing around lists and dicts from the start is a much more flexible strategy than trying to get all the encapsulation exactly right on the first try. If you don't have lots of time to spend up front UML'ing an object heirarchy for your big, complex application, you're probably better off sketching and iterating with JSON in mind (and yaml if humans need to edit it). As your application takes shape, it will become apparent where it makes sense to lock down functions and data into objects. This is especially true given that all of Python's standard types are inheritable classes.