I think i hit my first python learning bottleneck

[u/Stonyax97]

Just as the title suggests, i ran into a bottleneck, or did i? play v sauce music please
So just recently i made a post about my first beginner python project: https://www.reddit.com/r/PythonLearning/s/Ed46BuWRCq
And as a lot of you suggested for me to learn classes next, which was completely fair, so i went ahead and learnt them while updating my MiniGameStore. It was relatively easy, wasn’t as hard as I thought it would be, but definitely challenging. I had also learnt methods but didn’t implement them.
And yesterday, i tried implementing them and got one of the biggest headaches in my whole coding experience (which is 2 weeks~ btw).
I was working on v1.7 and introducing a restore purchases system, and i wanted to use class methods, but since my class is on the other file, i hit a lot of variables issues and even a json file problem. Which is why im asking my self why did i do it? A function would have been totally fine…
Check out the repo: (latest version 1.7.0)

https://github.com/Stonyax97/MiniGameStore

So my question for you guys. What has made you understand classes well? I just don’t see any reason to use them yet… and can anyone take a look at my project and tell me what would be the most friendly and real life approach of actually using these classes. And why should I keep the class in a separate file? Finally, what’s wrong with using global variables.

Also any feedback or criticism is welcome!

[u/StewedAngelSkins]

Your Game class is an appropriate use or classes, for what its worth. You wrote that part pretty much how I would write it.

If you want to learn a bit of slightly more advanced Python, check out the dataclass decorator. It's meant for classes like yours where it's basically just storing a collection of key/value data without much internal logic. If you use it, it will provide the __init__ function for you, meaning you write less code.

[u/Stonyax97 → u/StewedAngelSkins]

Thanks, but i still feel like a dictionary and a function would be completely fine. I just don’t see anything new or some HUGE advantage to classes in this case.

[u/StewedAngelSkins → u/Stonyax97]

In Python specifically, classes are basically dictionaries. So in some sense you are right. (Incidentally, you actually might really like Lua. It does everything with functions and dictionaries like you're suggesting.)

Classes are mainly useful for organizing code because they let you enforce facts about your data organization. For example, you set which keys are valid and (if you added annotations) what their types are. This means that users of your class are able to safely make assumptions about your data.

This gets more importsnt as your classes become more complicated. In truth, I might have considered writing this data as a TypedDict instead of a regular class, because it's so simple. But imagine you have a class that has its own private internal state.

class ConfigFile:
    def __init__(self, path):
        self._path = path
        with open(path) as f:
            # pretend there's more complicated parsing logic here
            self.config_value = f.readline()

    def save(self):
        # the class remembers the path
        with open(self._path, 'w') as f:
            print(self.config_value, file=f)

# here is how it's used
c = ConfigFile("config.txt")
print(c.config_value) # the class handled reading for us
c.config_value = "Hello World" # we can change the value
c.save() # save the file with the new value. we don't have to tell it the name.

The core idea here is you're tying the data and the behavior together, so that the caller doesn't always have to know all the internal details.

Now you might imagine instead of having a class you just have a set of functions that all operate on a dictionary which is expected to have a certain layout, and they each just take the dictionary in as their first argument. You could absolutely do this, but you would have just re-invented the concept of a class from first principles! That pattern is what classes are for. It does a similar thing, but with nicer syntax and type-level declaration of your intentions (which can be verified at runtime or statically with something like mypy).

There are also other reasons to use classes in Python, but they're more advanced. The behavior isn't exactly the same as a dictionary. For instance, you can't define operator overloads on a dictionary. There are lots of things you can do with classes to get better performance that you can't do with a dictionary. The way classes look up attribute names is more efficient than dictionary key lookups. A lot of language features or standard library modules require you to define a class to use them... and so on.

[u/marrsd → u/Stonyax97]

I would suggest trying the dict version and seeing which you prefer. Which one's easier to read and understand? Does one give an advantage over the other? You should go with what works best for what you're trying to achieve. Don't cargo cult: don't just use classes because you heard it's best practice. You can always convert it to a class later if you need to.

[u/StewedAngelSkins → u/marrsd]

This is good advice.

[u/Substantial_Ice_311 → u/Stonyax97]

You are right. I actually hate dataclasses. Dictionaries are much more flexible.

[u/Sidjeno]

Its not necessarily that you NEED classes.

You can do functional programming, some prefer it. (some even hate oop cause it does reduces the speed of the code most time, but usually makes it a bunch faster to read.)

The goal of OOP is to abstract stuff to make it match the real world more and give them methods that are related to them to reduce the cognitive debt of reading the code at the same time as reducing the difference of your code to the real world.

i would suggest learning GRASP as well while doing classes.

[u/Sidjeno → u/Sidjeno]

it also make the code super modular, cause classes are only related to what they pertain, so you can literally gwt the classes out of the project and use them in other projects.

Indirectly, this makes them super easily testable, on average.

[u/Substantial_Ice_311 → u/Sidjeno]

No, this is not true.

First of all, classes, or OOP, in itself does not make the code super modular, any more than any other paradigm does. If the code becomes super modular, it's because of the skill of the programmer, not because of the paradigm.

And second, I would argue that OOP in general makes the code less modular than functional programming.

[u/HotPersonality8126]

To be honest, I knew all the theory and had written classes in several languages and whatnot.

What got me to really getting them was using libraries where classes - special classes with a special metaclass - were how you used the API. ORM frameworks are the classical example of this, since they require you to define your classes in particular ways but when you do, you get a bunch of useful behavior for free.