2019-04-13 19:15:44

I'll keep this short and sweet, mostly because I don't have a lot of time to write a paragraph per question like I usually do.
1: What is the point of properties in a class?
2: Why do people sometimes inherit from an object class? I mean something like this:
class stuff(object):
Typing dir(object) revealed it's documentation, which wasn't helpful.
3: Sometimes, I see something like this:
def func(*args, **kwargs):
Or something of that similar nature. What are the args and the kwargs?

2019-04-14 12:25:52 (edited by targor 2019-04-14 12:29:52)

1: As you probably know, it is very bad practice to make object attributes public outside of the class. For this, you usually write getter and setter methods. Like this, you can make the attribute itself private and all read and write operations must use the public getter and setter methods. Properties are used to hide the fact that you can't access an attribute directly, mostly to make the code easier to read. So, the property takes your two defined methods, getAttr() and setAttr() and makes it so that you no longer have to type "object.setAttr(value)" but that "object.attr = value" is also valid. The difference is that "object.attr = value" now no longer accesses the attribute directly, but it is automatically redirected through the setter method.
2: In Python 2, each class had to derive from another class, no matter what. So, the most general class in Python is Object. This should no longer be necessary in Python 3.
3: Functions are usually defined with a set amount of parameters, for example def func(x, y). But what if you don't know how many arguments you'll get? A parameter with one asterisc in front of it is (for example *args) says that you don't know how many arguments you'll get. So, if the caller calls "func(1, 2, 3, 4, 5, 6, 7), args will now be a tuple with all given arguments and you can access it as usual with, for example, args[0]. If you put two asteriscs in front of a parameter, you say that you don't know how many arguments you'll get and that those arguments will be given as keyword arguments. So now, the caller can call "func(a = 1, b = 2, c = 3, d = 4, e = 5, f = 6, g = 7). This time, those arguments aren't saved in a tuple, but in a dictionary with their keywords as keys.
Hope that helps.

We are pleased, that you made it through the final challenge, where we pretended we were going to murder you. We are throwing a party in honor of your tremendous success. Place the device on the ground, then lay on your stomach with your arms at your sides. A party associate will arrive shortly to collect you for your party. Assume the party submission position or you will miss the party.

2019-04-15 20:51:45

I still don't see the point to writing properties. Imagine we have this class.

class stuff:
 def __init__(self,x):
  self.x=x

We can do something like this now:
something=stuff(3)
something.x+=3
something.x-=3

Now consider us having the same class, but with a property. Why? Why would we waste time on coding something that can be done in the code I provided above? What is the point of typing @property and creating getters and setters for a variable if we can just change it without those methods?

2019-04-16 12:44:27 (edited by targor 2019-04-16 12:46:52)

To use public variables can result in a greater number of bugs. Most times, getters and setters are simply one liners that return or change the variable, but don't forget you can make your getters and setters more than just that. The setter may, for example, directly reject values you don't want the variable to have. If the caller then does something he isn't supposed to do, this is prevented. Sure, you can do it without the extra lines of code, but you then break one of the most fundamental laws in object oriented programming: The implementation of a class should always only be known to the class itself and values should also be changed only by the class itself. This also helps when working in teams. When you write a class and someone else needs to use the class, he must not check your classes implementation and can just use it. When I code, I usually don't use properties but just use the getters and setters. I know, that all sounds like making an easier problem more difficult, and this may be correct for small programs, but it really don't hurt to get used to doing this. If you ever program for a company, they'll insist you do this.

We are pleased, that you made it through the final challenge, where we pretended we were going to murder you. We are throwing a party in honor of your tremendous success. Place the device on the ground, then lay on your stomach with your arms at your sides. A party associate will arrive shortly to collect you for your party. Assume the party submission position or you will miss the party.

2019-04-16 20:47:51

Hmm, interesting. Must I have properties for every single variable that is going to be changed outside of my class? Or rather, is it a good habit to get in to?

2019-04-17 10:25:29

Yes that's the idea. There shouldn't be any public variables left anywhere in your classes. But keep in mind most programming languages don't support properties, but just assume you work with the getter and setter methods directly. So, properties are nothing but a convenience in python.

We are pleased, that you made it through the final challenge, where we pretended we were going to murder you. We are throwing a party in honor of your tremendous success. Place the device on the ground, then lay on your stomach with your arms at your sides. A party associate will arrive shortly to collect you for your party. Assume the party submission position or you will miss the party.