Why do we need magic methods here?

The man, the myth, the legend.

Thank you. So, do operands behave differently within classes than outside of them and therefore need fine tuning?

The operators are the same everywhere, in that they trigger the same magic methods. For example, plus will always trigger the __add__ method. It's the magic method behavior that differs between classes.

Edit: meant to say operator instead of operand.

As for operands thing1 and thing2, they behave as their class magic methods are defined regardless of where they're being being used whether inside their own class or not.

All built-in types (int, list, string, set, dict, etc.) all have their magic methods predefined making expressions like 10 + 15 work everywhere.

Most user-defined classes, like Django models and class views, etc, aren't typically used in math expressions. That's why creating magic methods for classes is a fairly rare task. It's when users create a class that will be used in math expressions that the magic methods will need to be defined.

Sometimes creating the required magic methods is trivial by subclassing an built-in class which inherits all of the parent class methods. For example, Die, the parent class to D6 could have subclassed the built-in int class to get all of the int magic methods, but then the lesson on creating the magic methods from scratch would have been missed.

If not subclassing when creating a new class that will be used with operators, then all of the magic methods need to explicitly created.

Let's walk through an example of parsing an addition expression:

# thing1 is instance of Die class
# thing2 is instance of Die class
thing1 + thing2
# looks at operand thing1 first
thing1.__add__(thing2)  # self=thing1, other=thing2
int(thing1) + thing2
thing1.__int__() + thing2  # self=thing1
thing1.value + thing2  # the value is an int ("int1")
int1 + thing2  # int is built-in type implemented in C
# since int doesn't know how to add itself to a thing2 it calls: 
thing2.__radd__(int1)  # self=thing2, other=int1
# which calls
thing2.__add__(int1)
int(thing2) + int1
thing2.__int__() + int1  # self=thing2
thing2.value + int1  # value is an int ("int2")
int2 + int1
# the built-in int class knows how to add itself to another int 
sum_of_int1_int2 # int1 + int2

rather than go through setting up all these magic methods, could we not just have used 'd6.value' ?

Natalie Tan, using d.value where d = D6(), would depend on what you plan to do. Without the magic methods you would be limited to always using including the attribute name in your code d.value, or if __int__() was defined, calling int(d) to give you the numeric value for that object.

The purpose of the magic methods is to allow using the simple object reference d in whatever context you wish and have the object know how to behave in that context, whether it be adding, or in comparisons to other objects.

Please post back if you need more details!

Creating D6 and Die by sub-classing the int class is more complicated than a simple inheritance due to int being an immutable class. Sub-classing immutable classes is covered later in the coursework. Below is one way to sub-class int. Note the print statements are only to show which methods are run.

import random


class Die(int):
    def __new__(cls, sides=2, value=0):
        print("running Die.__new__")
        if not sides >= 2:
            raise ValueError("Must have at least 2 sides")
        if not isinstance(sides, int):
            raise ValueError("Sides must be a whole number")
        return int.__new__(cls, int(value or random.randint(1, sides)))

    def __init__(self, sides=2, value=0):
        print("running Die.__init__")
        super().__init__()

class D6(Die):
    def __new__(cls, value=0):
        print("running D6.__new__")
        return super().__new__(cls, sides=6, value=value)

    def __init__(self, value=0):
        print("running D6.__init__")
        super().__init__(sides=6, value=value)

$ python
Python 3.6.3 (default, Oct  3 2017, 21:45:48) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from dice_int import D6, Die
>>> d1 = D6()
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
>>> d1
5
# make a list of 6 instances of D6
>>> die = [D6() for _ in range(6)]
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
running D6.__new__
running Die.__new__
running D6.__init__
running Die.__init__
>>> die
[6, 2, 6, 4, 3, 4]
>>> type(die[0])
<class 'dice_int.D6'>
# compare instances using the inherited methods from int
>>> die[0] >= die[2]
True
>>> die[0] > die[2]
False

I misread your previous comment as "operator" instead of "operand". I've updated my comment above and add new comment on operators

Great question Iulia Maria Lungu! It is certainly possible to build the Die and D6 class by inheriting from int by it's a more advanced concept. The difficulty lies in int is an immutable class type. In addition to defining the __init__ method, the __new__ method also needs to be defined. The __new__ method creates the class instance, and the __init__ method initializes it. For mutable classes, the default __new__ method inherited from the base class object is usually sufficient.

I'll add a comment to my answer above showing how you can create Die and D6 by subclassing int.

The complexities of including math and comparison operators is independent of where the magic method resides. The repetitive calls are part of the structure of python. The built in types int, float, str, etc., are all optimized for performance when using operators. Most class definition is for structured data and rarely needs math support. Also, since __init__ is only run once per class instantiation there is little benefit in trying to optimize it.

Listing out the magic methods to override parent methods with the methods of the same functionality would be confusingly redundant. If a method is not present, it is looked for in the namespace of the first parent. So it’s a one-look-up delay.

Pulling in pieces or “entire classes” really only involves bring in a reference to a name space dictionary. So space is a non-issue. Use it if you need to augment a parent method.

Adding methods that aren’t explicitly needed isn’t DRY (don’t repeat yourself) and could provide a path to introduce errors. If a local Methodist needed, a complicated method will often refer to the parent’s method using super() to do most of the work and then tweak the result locally.

Post back if you need more help. Good luck!!!