I work in machine learning, and on my team we generally avoid OOP in Python, and we take great effort to avoid inheritance and abstract base classes when we do

I work in machine learning, and on my team we generally avoid OOP in Python, and we take great effort to avoid inheritance and abstract base classes when we do use object-oriented designs. In general, writing boring modules of functions with slight functional style, occasional metaprogramming, and lightweight classes, has worked extremely well for us. I would probably call our approach "module oriented design" because tend to think of modules as cohesive clusters of functions and topical little data structures (mostly just namedtuples, possibly using new dataclasses when we get around to it). The main times we invest much effort in custom classes tend to be times we are wrapping or extended third-party tools that themselves chose OOP, and their intended extension mechanisms involve inheritance. Think of writing a custom Filter for logging, or custom Layers in Keras. We don't like OOP in those cases, but we find it's better to stick with the convention of the library you're using, than to try to force it to fit into a different approach you like. But overall, I've worked on many multi-thousand line codebases in Python, often with web service wrappers around them, that are just collections of modules with plain functions. When I see this, I definitely would respect that development choice, and would believe it has a lot of upsides favoring it. Of course, I would also say that in the hands of skilled OOP developers, OOP solutions are also good and also have upsides. If I found myself on a team where OOP was the established lingua franca and people delivered good projects with it, I would try to adapt to that.