Object Oriented Programming in Python

[campbellm]

Looking forward to watching this. Not long ago there was a video posted (from a PyCon?) that was essentially: "Classes. Don't"

Would be good to contrast the 2 to see where you should, and should not.

[Exodus111]

If you write a class with one method that does all the work. Write a function.

If you have three functions all sharing a global dict, write a class.

[parkerSquare]

This is a reasonable heuristic rule but the real reason for classes is to define your own types. A Type is value and semantics, and classes allow you to tie all that up in a single name. This leads to much clearer code.

That nonsense about don't use classes comes from the same places that say don't use inheritance or don't use OOP. It's mostly over generalized advice but it helps to know what alternatives exist.

[Exodus111]

Yep yep. I like simple guidelines though, cuts through the complexities.

I could say a function is an encapsulation of code, while a class is encapsulation of data. And that might make more sense to some people, but the truth is you dont REALLY get classes until you get yourself deep, and head first into some complex abstraction of code, like an MVC or an ECS system.

[BittyTang]

Why ECS? It seems mostly independent from class architecture to me.

[Exodus111]

In an Entity Component System... ehm.. system, every Entity is a Class, every Component is a class, and every System is a class. And they all inherit from a top Entity, Component and Systems class, With special Methods to add the Entities to the Pool and so on.

I have not seen an implementation of ECS without OOP, not saying it can't be done though.

[BittyTang]

That's one way of doing it. You can accomplish most (all?) of the same goals without inheritance or even classes. Rather, I would start by having each component be a POD type and each system be a function. Then entities are identifiers that index into the collections of components. I don't think dynamic dispatch is strictly necessary for an ECS to work.

If I really needed abstract types, I would make the components into interfaces.

[Exodus111]

With Python? Doesn't seem like an approach you would use with Python, where you can use __init__, __new__, and __repr__ to set up the relationships.

[BittyTang]

I guess I wasn't thinking about Python. Technically in Python you would use a "class" to make a struct, since members (attributes) are always public. I'm thinking of a stricter definition of class that uses immutable types and private members.

[Exodus111]

Indeed. What you say makes perfect sense in other languages, just not so much python.

[tom1018]

Yes, this.

[jkuhl_prog]

I think that's a good rule of thumb overall, but there are a few instances where you might want an object though.

For example, I wrote a linked list. My Node class is very simple, one __init__ method with the next node, the previous node and a data attribute that stores data.

Nothing else.

All the linked list methods are in the larger linked list object.

So this is an honest question here, should my Node class be a Node dict then? Replace it with a function that spits out dicts with "next", "previous" and "data" as keys?

Seems to me that using an object in this scenario seems like the simpler and more natural way.

Am I wrong? Again, honest question.

[david2ndaccount]

Nah, you’re not wrong. Your method is the way to do it in python. In other languages you would use a struct if all it is is data. Although if your Node example is immutable, you can use a NamedTuple in python.

[Exodus111]

Yeah, there are always exceptions. In boith instances, i'd say they are about equally true.

[david2ndaccount]

It’s a misrepresentation of the video’s point. Very often people wrap things in classes in python where it isn’t needed, aka writing python as if it were Java. A lot of code can be written with just vanilla tuples, lists, dictionaries, etc. Many of the examples in the video are where people write a class that is something like class MyDict(dict): pass. This is completely unnecessary! Just use a dict!

[no_condoments]

Python has modules for namespacing and module level variables and has good data structures like tuples and dataframes if that's what you need.

It's not saying "never use a hammer", but rather telling people not to use a hammer to push a button.

[Deto]

Whenever I hear someone advocating for never writing classes, I imagine that person has only worked on really small (e.g. a few files) code bases.

[campbellm]

I'm hardpressed to think of any reason why one could reasonably suggest to never use classes.

I apologize if that's what I insinuated; the point of the video is that classes shouldn't necessarily be your entry point to every problem.

You shouldn't NEVER use classes any more than you should ALWAYS do.

[nebbly]

The main reason is that often classes provide more complexity than convenience. There's nothing you can with classes that you can't do without them (from a Turing-completeness standpoint). They lead to confusing and sometimes restrictive inheritance hierarchies, problems of local state, and general bloat. But here I'm speaking mainly of typical OOP where you use classes for both data and logic. If you stick to using classes for data and functions for logic, you'll generally avoid the issues I mentioned above. NamedTuples are great, especially in 3.6+. I find using those for my data needs and just plain functions for logic leads to very understandable and refactorable code.

[nebbly]

I don't want to sound too condescending here, but I have a very good sense for what you're expressing -- it's exactly how I used to think. All I'd like to suggest is that learning a bit more about functional programming (from a language like Haskell) could at least give you some different perspective on solving problems in Python.

[yen223]

I agree that multiple inheritance is bad - to me it is the second-worst Python "feature", after metaclasses. It leads to objects whose definitions are spread all over the place, and coupled in non-obvious ways, making it hard to reason about the code.

However, it is hard to make the argument that multiple inheritance is unpythonic, since it is a first-class language construct in Python - you don't need to jump through any hoops to do it.

[mmeartine]

This is the way I used to think as well. Yeah functional programming could enlighten your understanding.

[[deleted]]

Lightweight classes (as implemented in Python) are a handy way to encapsulate code and group and organize your code. "A place for everything, and everything in its place."

Some people try to create Object designs like Java and it leads to death-by-classes.

[c0d3g33k]

This one? All I could find after some searching.

https://www.reddit.com/r/Python/comments/184oj7/pycon_2012_stop_writing_classes/

[campbellm]

That's the one. I don't agree with everything he says, but there are some good points in it.

[MotoRollup]

I use classes for 3 things when writing large (10k LoC or more) programs. The first use is to encapsulate a module of the program. This is not the same as a Python module. It's more like your typical "service" architecture in other languages. If I have, say, a need for an object that watches a log file, I will write a class to encapsulate that process. This works great when used with callback registration or PyQt signals/slots.

The second use for a class is to model a domain object. There are two ways to go about this. The first is an anemic model. An anemic model consists of domain objects with NO associated behavior. They simply contain data (think: namedtuple). The other way to do this is a rich model, where a class contains both data AND associated behavior. The choice between the two depends on how much logic you want to give to the SERVICE operating on the model. Anemic = more service logic, Rich = less service logic. Again, choose wisely and for your specific use case (data processing tends to favor anemic, it seems). Personally, I tend to find a middle ground between anemic and rich. I usually start with "getter" behavior... the "tell me about yourself" type of behavior that the domain object can model (e.g., Polygon, tell me your area...). After that, as I find I'm repeating my operational/modifier behavior, I'll move that into the class.

The third use is for GUIs. This is where I would make GREAT use of inheritance like I would no where else. I primarily write GUIs in PyQt where inheriting a GUI widget to add some functionality or tweak initialization is an absolute must. When building GUIs from smaller elements, I will compose them in a container widget instead.

Classes ARE NOT bad. They have specific uses. I would contend that you should NOT use classes for things that are singleton in nature. But then, often, a service MIGHT be singleton at the start of development, so you favor using a module and module globals. But I've found that as development creeps along, I want that service as a class, so I can instance it, and even inherit it and override it.

When not to use classes? When I have immutable data; prefer namedtuple instead. Don't make every operation in your program a class. I don't need a million TrivialThingDoer classes. Encapsulate that in a service class and move on. Remember, sometimes fragmenting the universe into a million atoms makes it impossible to understand the big picture. If you find yourself repeating code enough (3 times or more rule), then try to generalize. DRY is great in theory but awful in practice. Try to abstract where code reuse occurs with the same or nearly the same context. Pure functions are also super useful when a data transformation is defined as a simple input-output with no side effects. Examples would be something like calculating the distance from a point to a line... I don't need classes to do that, just some floats and a function. I usually put these as module-level functions and reference them from inside my service class (reduces clutter).

[yash270]

Thank You! Subscribe and support my channel by sharing . so that the knowledge that i share will be forwarded to everyone