Skip to main content

A Hundred Days of Code, Day 004 - Class Attributes and Inheritance

Learnt about Class Attributes and Inheritance, today.

Notes

  • The way we write functions/methods and define classes might look similar,
    class CrazyTalk(object): and def how_now_brown_cow():
    The way they behave/execute, though is wildly different.
    Classes run / spring to life as soon as the program launches.
    Functions don’t, unless they are called.

  • Realised that objects are containers.
    What you can do with the object depends on what is in it.
    Does it hold a dictionary with various methods to modify it?
    Does it just hold a bunch of text?
    Reminds me of media formats as containers.
    A mp4 file is not just an mp4 file.
    The video resolution could vary from one file to another.
    The type of audio encoding could be different.
    It could carry multiple streams of audio or video or other metadata.
    What you can do with the file or where you can play it, depends on what is inside it.
    Same with classes and objects.

  • Any thing that we define inside a class, is an attribute. (methods, variables etc.) Reuven made a point of stressing this, so writing this down.
    If I just define a variable and try to use it, I’ll get an UnboundLocalError. I need to use className.variable when I call it.
    So I can just write a variable like so

class SomeClass():
    crazy_var = 'Muahahahaha'
    def __init__(self):
        print(SomeClass.crazy_var)

and then call it with SomeClass.crazy_var or when I do it after I define __init__ then I can just directly define it as SomeClass.crazy_var (which sounds more logical to me), like so

class SomeClass():
    def __init__(self):
        print(SomeClass.crazy_var)
SomeClass.crazy_var= 'Muahahahaha'


  • A class attribute is associated with the class itself, while object attributes are associated with the objects that are created from the class.
    So with car.wheels, the wheels are associated with the car class, but when I use car to create a Ferrari object, and it has Ferrari.white_wall_rims the rims are an instance attribute that belong to the Ferrari object / instance and not the car class it was made of.

  • If I ask for an object’s attribute and it isn’t there, then Python goes looking upwards to check if the class has it. In the previous point, if I go Ferrari.wheels it’ll work, because Python will check the Ferrari object and if there are no wheels in there, it’ll go check cars.

  • Name your attributes carefully.
    Don’t have the same names between class attributes and object attributes.
    Use your head!
    Don’t do that!

  • When we create a class, that is identical to another with one or two teeny exceptions, when they are so similar that I base the new one on the old one — those new classe are said to be inheriting from the old one. They have an is-a relationship.
    For e.g. a doggie is-a floofy animal.
    A teddy bear is-a floofy animal too.
    Both of them inherit their floofiness from the floofy animal class.
    I can write that as class Doggie(FloofyAnimal):

  • Note: Methods are attributes on a class. They are not attributes of the instance object.

  • Note: If you have an __init__ method in your inherited class, the instance will not look for __init__ variables/details in the parent class.
    (it’s like this in Python, Java/C++ can get stuff from the parent / grandparent. this is so, because with Python, everything is a live object whereas with the other languages, the __init__ stuff are declarative rules with orders of precedence (a la CSS) and the class comes alive only after all the rules are parsed.)

  • If you do want to inherit something from the parents __init__, then you explictly get it by using super(). as in get it from the supervisor above, i guess? I’d add a line like this to my doggie class

class Doggie(FloofyAnimal):
    def __init__(self, name):
        super().__init__(name)

        And then it will pull the name from the Floofy Animal class if it’s in there.

  • Use inheritance only when it makes sense. No need to go hog wild.

learning / feedback/ experiences from doing exercises

  • Slowly getting the hang of list comprehensions. I should practice them more.
    Because they are very easy to read later.
    Just that, I get very confused while writing them.
  • Doing the exercises is slowly getting easier
  • Reuven is very hands on, has tons of jokes, and makes tons of typos.
    I’ve gone from eyes glazed, looking at the his code and struggling to understand to yelling at the screen when he mistypes something :)
    Shows that I am learning :)
  • Python Tutor is very handy to see the the thousands of mistakes I make.
    Even that interface does not quite make me understand, but it gets me 80% of the way there.
    (like when a return statement of mine was nested in a loop instead of being out at the end of the for statement.)

Read all about my OOP journey here