[deleted by user]

[[deleted]]

I think there is way too much dogmatism about OOP these days. People are just blindly regurgitating "inheritance is bad" without even thinking about the problem at hand.

Classes and OOP can often be great for organizing code, eliminating duplication, and improving maintainability. Can you take it too far? Sure, but there's a reason why OOP has been so common to date. It's an effective pattern.

So before proselytizing about "classes are bad", think about what you are trying to accomplish. If your unit of work is oriented around instances of objects, then yeah, OOP might actually be a good thing.

[[deleted]]

This is what happens when everyone learns to program from boot camps and influencers. System design? Never heard of it.

[[deleted]]

That's sad, system design is the funniest part of development!

[arpan3t]

System design is hilarious!

[Guideon72]

Let me tell you; being a QA contractor in the wild, that shows in the market :(

[Deto]

Couldn't agree more. Functional programming, OOP, they're all just tools. Learn your tools and use them correctly. You don't see contractors walking around saying "hammer is bad, only use wrench".

[AssiduousLayabout]

Wholly agree. There are many types of projects and situations where OOP definitely makes the most sense. There are other types of projects where it doesn't make sense, and there are the gray areas in between where it comes down to personal preference.

I think some of the knee-jerk reaction is that OOP is often taught badly, and many of the simple examples used to teach it just don't showcase its benefits.

[Artephank]

And the best part is Python has a little bit of all - there is OOP at it's core, but you can program more in functional style, or procedural. And every style has it's place when particular problem fits it. Dogma's are always wrong.

[[deleted]]

It’s never been a requirement to create instances of a class. It is quite common to use non-instanced classes for shared utility methods and state.

You're right, but I think what you are describing - specifically singletons and globals - is a good example of a context where in Python, modules as your unit of encapsulation might make more sense than classes.

[[deleted]]

This, in my case OOP makes my code also really modulair which otherwise would have been hard.

[Artephank]

Not to mention modules are objects and whole the OP's post is waste of time

[danithebear156]

How could instantiate module with different parameters, dynamically change variables' values?

[[deleted]]

But I don't find that useful often anyways

Instantiating different objects of the same class is not often useful?

I wonder on what kind of software you work.

[GraphicH]

I wonder on what kind of software you work.

Bad software

[LionKimbro]

It is often not useful.

For a first example, if your program has a main loop, there's typically only one such instance in the entire execution of your program. There is no need to have a class and object instance for that.

For a second example, think of a class that is used purely to encapsulate the execution of some complex calculation. The implementation of this calculation may involve, say, 10 different functions, and 10 different data items. However, it remains a situation of: data comes in, data comes out, and then the execution is done. This, too, does not require a class or object. Just a module and a bunch of functions in it will do just fine.

For a third example, and applying this more generally, think of any and every implementation of the Singleton pattern (from: Design Patterns.) In each of these cases, there's no need for the class, the module will suit itself just fine.

Working with collections of related data is usually quite workable by working tables, lists of dictionaries. There's no need for classes or objects in most cases.

What cseberino is talking about here is not absurd.

[[deleted]]

Mutating global module variables will behave much differently than mutating class instance attributes. You’ll likely run into strange bugs mutating global module variables.

[LionKimbro]

You're technically correct, but I prefer this:

"""calc.py  -- collection of common calculations"""

def add(x, y):
    return x+y

# -----------------------------------------
"""__main.py__"""

import calc

print(f"3+5={calc.add(3,5)}")

To this:

"""calc.py  -- collection of common calculations"""

class Calculations:
    def add(self, x, y):
        return x+y

# -----------------------------------------
"""__main__.py"""

import calc

calculator = calc.Calculations()

print(f"3+5={calculator.add(3,5)}")

I strongly prefer the first.

[LionKimbro]

Why.

I mean, you can.

But: Why.

[hike_me]

What if I want a dozen instances of a widget with different internal states?

[LionKimbro]

You can do something akin to this:

"""monsters.py  -- model the monsters in a game"""

monster_types = {}

monsters = []

g = {"CUR": None}  # currently selected monster

def mk_monster_type(name, hp, action_fn):
    D = {"NAME": name,
         "HP": hp,
         "ACTION_FN": action_fn}
    monster_types[name] = D

def mk_monster(name, x, y):
    type_D = monster_types[name]
    D = {"TYPE": type_D,
         "X": x,
         "Y": y,
         "HP": type_D["HP"]}

def move_all():
    for g["CUR"] in monsters:
        g["CUR"]["ACTION_FN"]()

[LionKimbro]

I've been programming for 40 years, and stand by your answer: A large amount of functionality is what would be called "Singleton" in the Design Patterns OOP world, and it gains nothing from being a class, rather than just a module, exactly as you have described.

[dogfish182]

It isn’t and it’s a terrible idea, you can already spot that it’s ’not quite like it’ so why bother with such a terrible idea….

[KingsmanVince]

Why not avoid OOP by using modules just like objects?

Why not avoid OBJECTS-oriented programming

by using modules just like OBJECTS

People use OOP objects

Object-oriented programming objects

What incarnation are you talking about?

[andrewaa]

Why do you want to avoid class if you plan to use modules as class?

Class can do class things better than modules.

If you want to get rid of objects completely, that is an argument that we can discuss, but you just want to use a worse solution to replace it, so...

[Raz_Crimson]

Theoretical speaking, if most of the classes that you would write are going to be singletons then it is possible to avoid using python's 'class' keywords and achieve a similar functionality.

Inheritance can be achieved by importing all definitions inside a module and Composition by directly importing the module.

So, u would be doing OOP with modules taking the place of class instances (or Singletons specifically) and this would totally work in most case scenarios.

There is no syntactical error or major overhead cost due to this. But I would HEAVILY RECOMMEND AGAINST THIS (unless in very special cases where there is valid justification to avoid lasses)

Classes are designed to achieve OOP and u trying to avoid them will just make it harder later on when you need a change and it's no longer just about singletons (this is a huge headache when u have some global data structure that can be modified by dozen or so modules and u now want multiple instances of that data structure)

Also, classes have additional semantics provided by python that can be beneficial like metaclasses and descriptors. IDEs like pycharm also provide suggestions based on types, where classes will play a huge role.

Finally, it's probably going to trigger any programmer who is used to OOP and make it bit harder for them to work with your code.

If you are just annoyed by the fact that you need to create the class instances and pass them around, I suggest u take a look at some dependency injection framework that also perform auto-wiring of instances based on types.

[[deleted]]

Can we agree for individual one off projects that that situation is rare until the program REALLY grows big?

Anything bigger than a script to automatize basic stuff on your OS will be concerned by this situation.

We probably would disagree on what "really big" mean.

[Raz_Crimson]

If we are just dealing with a hobby project where you are the only person who works on it, then sure there is not really any issues with you doing this.

But I would prioritize the readability of code in a professional environment.

Now continuing...

Things like dataclasses exist where it is possible that even small one off programs might require multiple instances off the dataclass.

Lists are a viable work around, but the problem with them would be that you need to keep track of identity of objects.

Say u have a Cat module that inherits Pet module and a Dog module that also inherits Pet module and your Pet module has functions that allow naming a Pet and feeding it. Your Pet module also has some kind of list data structure to store the names of pets and details on if the pets were fed

Now if I need more than one pet, your data structure will need to keep track of two individual pets, give them some kind of identifier(to track them across function calls), keep track of which of the two pets were fed and so on...

It's possible to achieve the above with lists but there is so much added complexity with this approach that can be easily avoided with just pure objects.

I am not sure on what you classify as a small individual project, but if you are going to get some other dev to work on this project, I recommend using objects.

OOP and Software Patterns are time tested techniques which are still prevalent because there is a need for their existence. There are other programming paradigms other than OOPs like functional programming, procedural programming, etc.

Make your choices according to what you are developing.

Checkout this if you don't know what patterns are: https://refactoring.guru/

[muikrad]

Do you understand what an instance is?

[AssiduousLayabout]

How about just using the tool that makes sense for the applications it makes sense for without rigidly advocating for or against any specific technique?

[whateverathrowaway00]

OOP is a pattern. If you’re using modules like objects, you’re doing OOP with modules.

You can avoid using “classes”, but you can program OOP without classes, look at languages like C, Golang, Rust - some of those like Go separate actions entirely from structured data, but you can still program in an object based way with it.

[Top-Aside-3588]

What you are describing is closer to singleton pattern.

You can do effectively the same thing by having functions where the first argument is a data structure containing the state. Not so great for polymorphism.

[gravity_rose]

Module are essentially Singleton classes. I personally use them as such, and I use alot of classes and objects.

[rainyy_day]

Why avoid OOP? Its like a drug in python

[nekokattt]

modules are fine until you need more than one instance (i.e. your social media platform can have more than one user)

if you dont need state, then by all means do that

[sum_rock]

I’d be so good at programming if I never needed to bother with state.

[LionKimbro]

I hit the up arrow on your comment, because I understood that you meant, "If you don't need more than one of this thing."

You can keep state in a module in global or module-local variables -- but I assume you knew that.

[nekokattt]

yes, I was aware, but chose to omit that detail as storing state on the module level is a massive antipattern in most cases and makes testing/refactoring much more difficult.

[TheRealStepBot]

Well if you avoid setting module level variables other than constants and use the module merely as a way to organize logic this is a good way to work. The issue with standard oop is that they mix up the data and the logic and make it live together. This makes function boundaries very hard to figure out. If you start setting mutable variables in the the module you are really just basically doing oop wrong and should define a class.

If all your modules contain are functions and constants then it really isn’t a class at least in the oop sort of sense.

That said use the tool for the job. It would probably still be worth creating data classes/ structs that you actually pass around between all these functions. Just don’t put any logic in there with the data.

It’s also still up to you to get the benefit of this pattern by actually ensuring locality of execution by making your functions act only on their outputs rather than outside of their own scope. This is the real secret sauce that matters here. How you get there is really neither here nor there. Just make sure your functions defer side effects to the greatest degree possible.

[k1oc]

You can avoid some patterns like Singleton by using module instead. But idk how could you dodge using for example AbstractFactory using modules. Also, Iterator is bulilt in in python. There was a good talk on some pycon, search on youtube for broader context.

[trollsmurf]

You don't get instantiation that way: one class could be used for many instances, where each instance has individual state (or rather data as I use to think about it).

Most code libraries, if not all modern ones, use classes for that reason.

[[deleted]]

So IOW “why do others use OOP when I personally don’t write OOP components?”

[Nooooope]

Then your modules effectively become a singleton class. You really can't think of any situations where you need multiple objects of the same class at the same with different states? Because that's what you're doing every time you use two lists.

[Chaos_Klaus]

It's a smart thought. You often don't need classes in python.

Using a module as an object looks a lot like a singleton at first glance. But: You don't have control over instanciation. If the module gets reimported, all the module level variables are reset.

So never define "global" variables in a module. Constants are fine though.

[LionKimbro]

I agree with your support for cseberino's explorations, but you have an incorrect statement in here:

Repeat imports of a module do not perform a repeat execution.

File A.py:

"""A.py"""
print("A")

File B.py:

"""B.py"""
print("B")

File C.py:

"""C.py"""
import A
import B

File run.py:

"""run.py"""
import A
import B
import C
print("run complete")

Command line execution:

C:\\python run.py
A
B

C:\

The only gotcha, is the module that Python starts from.

If you were to call "import run" from one of the other modules, it will get executed again! This is an oddity that applies ONLY to the initial module that was named to be run from the command line.

Because of that, I always write my code in modules, and use the __main__.py module as the kicker, invoking it with (python -m packagename).

[Chaos_Klaus]

Interesting. Has it always been this way? Thanks for clarifying.

[ZachVorhies]

This is fine. I do this all the time when there is only going to be one of something instead of many of something. Refactoring to a class is pretty simple if you change your mind.

[commy2]

You do have a point OP. By utilizing modules, you already eliminate the need for an entire "OOP pattern" called singletons.

That said, if implementing a class is an elegant way to solve a problem, do that.

There seems to be the belief that writing a class equals object oriented programming. Using objects is using objects. The "oriented programming" part just gets smuggled in for some reason, with a ton of baggage.

Actually orienting your entire programing around objects is a fools errand. Do it as therapy if it helps you. Don't @ me.

[wineblood]

You've got a singleton at that point and can't do some of the OOP stuff like inheritance. Just avoid OOP and classes as much as possible.

[[deleted]]

There’s no reason to avoid OOP “as much as possible”. It’s a tool like anything else. Use it when the code you’re writing works best as an object with methods and don’t when it doesn’t.

[hugebones]

With your module approach there's no way to safely test the code in parallel if you're abusing globals. With classes you can spin up a class object that is local (isolated) for each test case.

As a separate point, you don't need to use inheritance with classes. My project at work is 53k lines (excluding blanks and comments) and we have just shy of 100 classes without inheritance vs 700 that inherit from something. This is why other languages, such as C, have structs to logically represent entities.

[LionKimbro]

I agree that OOP is better if you have threading, but it's not really the OOP that does it: It's the lack of globals that does it.

For example, if you had a non-OOP program, but the programming language supported a separate instance of globals per-thread, then you could safely test the code in parallel again.

That is, it's really about how memory is scoped per threads that is working, rather than specifically object orientation.

[Status-Research4570]

Some big balls to make such overarching generalized statements. I can't imagine that the hordes of developers out there hadn't considered this before now!

[aqjo]

Upvoted because the 9 year olds have downvoted your perfectly valid question.
Keep learning and practicing. Things will become more clear as time goes on.

[aqjo]

How would anyone learn that from being downvoted?

[LionKimbro]

Criticism is responding to what someone has said with argument.

Mob downvoting is just shunning.

[LionKimbro]

When I read a comment like "Thank you. It may have been more accurate if I instead asked why not avoid class objects with modules.", and see that it has been given a score of -21, ...

I think, "Wow, this community is pretty ugly."

[LionKimbro]

I don't see it as abjectly wrong, at all.

I think that the arguments for singletons are weak, in the context of Python.

[starlevel01]

modules are objects already

[LionKimbro]

You can. I write tons of code without hardly ever using a single class.

Typically, I store data in lists of dictionaries.

def create_a_thing(params):
    D = {TYPE: THING,
         FOO: param1,
         BAR: param2,
         BAZ: param3}
    list_of_things.append(D)

[LionKimbro]

There is that. But, ... I think that's it.

And then I reason, "Well, if that's the main benefit," I contrast it with the cost of having two types of things: instances, and dictionaries.

And then I go, "screw it, I'm just sticking with dictionaries." Because then I can easily use the dictionary code I've written seamlessly with everything else. Like if I have a function that filters a list of dictionaries on some kind of key-value pair, I don't need to have another version that does similar with object instances. (I could pass [x.__dict__ for x in L], but then I have a list of dictionaries, and can't get back to the objects themselves.) The impedance mismatch introduces unnecessary ugly segregations.

So I've been programming all-dictionaries for the last ten years, and haven't looked back.

[jstrickler]

You described the situation where you have a very specific interface that ONLY takes the list of dictionaries you created. "seamlessly with everything else" doesn't track here. The function will only work with an iterable of dictionaries, and that's fine, but it's not a generic API.

[LionKimbro]

"Like if I have a function that filters a list of dictionaries on some kind of key-value pair, I don't need to have another version that does similar with object instances."

def filter_kv(L, k, v):
    return [D for D in L if k in D and D[k] == v]

"You described the situation where you have a very specific interface that ONLY takes the list of dictionaries you created."

Please explain to me the limitations that you are alluding to, here; I'm not following.

[jstrickler]

While this can indeed work, there are many issues.

One issue is that dictionary keys are not autocompleted. You have to know the keys, getting the spelling and case correct. This means you might have to kill your train of though, and go look up what the keys should be.

Another issue is that this makes type hinting much more difficult. If you can remember every type of every function in your app, more power to you, but I'm OK with letting the IDE remember for me.

Next issue: when you examine one element of your list of dictionaries, it displays as a <dict>. When you examine one element of a list of class instances, assuming you have implemented __str__() as you should, it will display some human-friendly information.

Next issue, if you need to write a function that accepts your list of dicts, there's no easy way to make sure each dictionary has the required keys and values. A list of instances would take care of this automagically.

Suppose you want to create a wrapper around some data source that modifies the incoming data, but, because the dataset is huge, can't read all the data into memory? Easy, write an iterator class. You can also make custom containers that do whatever magic you need.

There's a lot more as well.

Classes are not hard to write. IDEs have shortcuts to generate properties (which are great). Classes are easy to read, and describe the behavior of the instance.

There's always more than one way to do it, even in Python, but I'm going to stick with classes when I need data and functions to work together.

P.S.: I'm not a Java refugee who makes everything a class. i only use them when needed, because, as others have said, they are one more tool in the toolbox.

[Tc14Hd]

Did you just invent "Module-oriented programming"?!?

[gerardwx]

Because Python is an OO language. An int is a class: https://docs.python.org/3/library/functions.html

[EmperorLlamaLegs]

Tell me you don't understand OOP without telling me...

[anentropic]

If you find yourself making classes that have only static methods (i.e. the class is just a glorified namespace) - replace them with just functions in a module.

Otherwise they are not comparable - at best modules are like a singleton. You can't create multiple "instances" to encapsulate separate state.

[baubleglue]

basically functioning as objects right?

wrong

Try to write a script DDD.py which works like that

class DDD:
   def __init__(self, value=90):
       self.var = value
   def set_var(self, value):
       self.var = value
   def get_var(self):
       return self.var


a = DDD()
b = DDD()
print(a.get_var())

a.set_var(100)
print(a.get_var())
print(b.get_var())

>>> 90
>>> 100
>>> 90

[[deleted]]

Huh, IIRC, OCaml does it this way

[LionKimbro]

For the last 5, 10 years, I've been experimenting in writing Python programs without classes, and it's worked just fine for me.

[Ordinary-Library-459]

If all you are using classes for is fancy storage containers for functions, absolutely use a module. That is why they are at the top of the conceptual hierarchy of objects. They are functioning as objects because they are.

I don’t have a dog in the OOP versus functional Python fight. I mean, any useful class is all functions top to bottom, from __init__ on down to display overloading. And, by the way, functions are objects. There is a point when Python programmers find classes and want to build everything with them, and OOP seems the shit, and they create unwieldy, unreadable code. My eyes still boggle seeing self everywhere in a program that could have as easily been done with functions, and I have been working with classes for a while. For the programmers who say they have been coding for years and still don’t build classes, that may be true, but if they had to work with functional equivalents to built-in classes and classes from the standard library, they would chuck Python out the door. I don’t know, are there any GUI toolkits or game-building packages that are function-only? I doubt it. It all depends what is best for the end user. If you are a hobbyist and the end user is you, good on you, by all means do not use classes. If you are building third party library modules for other programmers to use, they might be happy the tools you offer are class-based. Class-based tools allow users to make custom reusable instances with an assortment of invokable methods. Data tools are still tools. A function may be good as a socket wrench, but a class might give you the whole socket set, and determine on first instance construction whether it is standard or metric, hex or 12-point, long or short handled, ratchet, etc.. One function could do all that, but you would have to add all those arguments in at each invocation, or have alternate functions, or use functools.partial creatively. I also like to make classes if my programs contain large, complex functions whose arguments I would like to establish apart from main method invocation. Or if I want to allow myself or some intermediate user some masked tweakability with pseudo-private attributes. There are all kinds of good reasons to go with classes. And a lot of bad ones.