Corrected exercises: classes and objects, COMP 202 at McGill

a) class Student: then def __init__(self, name): then self.name = name and self.marks = []. The objects: ana = Student('Ana') and ben = Student('Ben'). The call does not mention self, Python supplies it, and __init__ is not called by name: writing Student('Ana') creates the object and runs __init__ on it. Note that self.marks = [] must be inside __init__, so that each student gets a fresh list, for the same reason as the mutable default argument of the functions set.

b) self is the OBJECT the method was called on, and Python supplies it automatically from what stands to the left of the dot. In ana.average(), self is ana, so self.name is 'Ana' inside that call. The word itself is a convention rather than a keyword, and using another name works and costs style marks. The habit that makes the whole chapter easy: read ana.average() as Student.average(ana), which is literally what Python does.

c) TypeError, average() takes 0 positional arguments but 1 was given. The message is confusing at first sight because the call ana.average() looks as though it passes nothing, and it is exactly right: the object is passed as the first argument, and the header did not declare a parameter for it. Every method of a class takes self as its first parameter, including the ones that seem to need nothing.

d) First, an object can exist without them, so a method that reads self.marks raises AttributeError on an object whose other method has not run yet. Second, nobody can tell what a Student is by reading one place: the state is scattered over the file, and the class no longer documents itself. __init__ is the one place where the full state of an object is declared, and keeping it complete is what makes the rest of the class safe to write.

e) It is usable: objects can be created, and attributes can be attached to them from outside, ana.name = 'Ana'. It is also useless as a class, because nothing guarantees that two Student objects have the same attributes, and any method may find a missing one. That is what __init__ is for: it does not create the object, Python does that, it INITIALISES it, and its real job is to guarantee that every object of the class starts complete.

a) Declared in the class body, count = 0, outside every method, and increased inside __init__ with Student.count = Student.count + 1. Naming the CLASS on the left is what makes the increment act on the shared value; that is also why the line reads oddly at first, since everything else in __init__ is written with self.

b) Reading self.count works, because a name not found on the object is looked up on the class, so the first object reads 0. ASSIGNING self.count creates a brand new attribute ON THAT OBJECT with the value 1, and the class attribute is untouched. The second object does the same and also ends at 1. The class attribute stays 0 for ever, and each object claims to be the first. The rule to keep: reading falls back to the class, assigning never does.

c) The two students share ONE list, so a mark appended for Ana appears in Ben's marks as well, and the class average is computed twice over the same data. It is the mutable default argument again, in another costume: a mutable object created once, at definition time, and reached by everything that comes later. The repair is the same, create it per object, self.marks = [] inside __init__.

d) It is legal, since Python attaches attributes on demand. What a reader loses is the guarantee: from that line on, some Student objects have a year and others do not, and any method that reads self.year works on one object and raises AttributeError on the next. It also defeats the point of __init__ as the one place where the state is declared. Adding an attribute after the fact is a debugging convenience, never a design.

e) The rule: does the value belong to ONE object or to the KIND? A mark, a name and a balance belong to the object, so they are instance attributes. A count of the objects created, a constant such as a passing grade of 60, or a default interest rate belong to the kind, so they are class attributes. The honest uses are exactly those: shared constants and shared counters, and everything mutable per object goes through self.

a) It is the default text representation: the class name and the memory address of the object, which is all Python can say about an object whose class has not said anything. The repair: def __str__(self): return self.name + ', average ' + f'{self.average():.1f}'. From then on print(ana) shows that line, and so does str(ana) and an f-string containing the object.

b) Because print calls it and prints WHAT IT RETURNS. A __str__ that prints instead of returning prints its text at the wrong moment, returns None, and then print raises TypeError, __str__ returned non-string. It is the print against return distinction of the functions set, in the one place where the language checks it and says so.

c) It answers False. Without __eq__, the equality sign on two objects compares IDENTITY: it asks whether the two names refer to the same object in memory, not whether they hold the same values. Two students built by two calls to Student are two objects, so they differ. That is the right default, since Python cannot guess which attributes make two objects the same.

d) def __eq__(self, other): return self.name == other.name. The consequence for in: the operator uses equality, so ana in students is then True for any student of the same name, and list.remove and index follow the same rule. That is convenient and it is also a promise: two objects that compare equal should behave the same everywhere, so an __eq__ that ignores the marks says the name IS the identity of a student.

e) TypeError, less than not supported between instances of Student. sorted needs to compare, and comparison is __lt__, which the class does not define. The two ways: give sorted a key, sorted(students, key=lambda s: s.average()), which is the one to prefer since it says on what the order is based; or define __lt__ on the class, which makes the order a property of the type and is right only when there is one obvious order.

a) The invariant: self.marks is a list of numbers, each between 0 and 100 inclusive. __init__ establishes it in the simplest possible way, self.marks = [], since an empty list satisfies it, and every later change goes through the class. Starting from an empty state is what makes an invariant easy to establish, and it is also why a constructor that accepts a list from outside must validate it.

b) if not (0 <= m <= 100): raise ValueError with a message naming the value; otherwise self.marks.append(m). With 130 it must RAISE, not ignore and not clamp to 100: the caller passed something impossible and needs to know, whereas a silent clamp would put a mark in the list that nobody ever gave. This is the functions set rule again, raise rather than return a special value.

c) It is not guaranteed. Nothing in Python stops the caller from reaching into the list and appending anything, and the class cannot notice. The underscore convention, self._marks, changes nothing technically and everything socially: it says this is the inside of the class, and a reader who writes ana._marks.append(130) knows they are breaking a promise. Real protection would mean returning a COPY from the accessor, which costs a copy each time and is rarely worth it in a first course.

d) def average(self): if self.marks == []: return None, then return sum(self.marks) / len(self.marks). It is a method because it is DERIVED from the state and must follow it: an attribute computed once in __init__ would be the average of an empty list at that moment and would then be wrong after the first mark is added. The general rule: store what is independent, compute what follows from it.

e) A stored attribute is right when the computation is expensive and the state changes rarely, for instance a total recomputed over ten thousand marks in a program that reads them once. What must then be maintained is the agreement between the store and the state: every method that changes the marks must update the total, and that duty is exactly what makes a stored derived value a source of bugs. The compromise is to keep it inside the class, so that only the class can get it wrong.

a) Yes, the caller sees the appended mark: the parameter and the caller's variable name the same object, and appending changes that object. No, the caller does not see the reassignment: student = Student('copy') rebinds the LOCAL name inside the function and leaves the caller's object alone. It is exactly the list story of the foundations set, and the rule is the same, mutating is visible, rebinding is not.

b) In place: def add_interest(self, rate): self.balance = self.balance * (1 + rate), documented as changes the balance of this account and returns None. Pure: def with_interest(self, rate): return Account(self.owner, self.balance * (1 + rate)), documented as returns a NEW account, this one is unchanged. The two names are different on purpose, since a reader who sees the result of the first assigned to something has spotted a bug.

c) a is b, which asks whether the two names refer to the same OBJECT, while a == b asks whether they are equal in the sense the class defined. Two students built separately with the same name are equal under the __eq__ of exercise 3 and are not the same object, so is answers False and the equality sign answers True. That pair of questions is the same one the copying exercise of the structures set asked about lists.

d) import copy, then twin = copy.copy(student) for a shallow copy or copy.deepcopy(student) for a deep one. A shallow copy of a Student shares the LIST of marks: the two objects have different name attributes and the same list object, so a mark added through one appears in the other. It is the slice copy of a nested list, one level up, and the answer is the same, deepcopy when the attributes are mutable.

e) A method should return self when the class is designed for chained calls, report.add(x).add(y).sort(). The risk is that it then looks like a pure method: a reader who writes new = old.add(x) believes old is unchanged and it is not, since what came back IS old. Python's own convention avoids this by returning None from mutating methods, and a first course is better off following it.

a) class Account: then def __init__(self, owner, balance=0): with self.owner = owner and self.balance = balance, plus a validation that the starting balance is not negative. The __str__: def __str__(self): return f'{self.owner}: {self.balance:.2f} dollars'. The default of 0 is immutable, so it is a safe default, unlike a list.

b) def deposit(self, amount): if amount <= 0: raise ValueError, else self.balance = self.balance + amount. def withdraw(self, amount): if amount <= 0: raise ValueError, then if amount > self.balance: raise ValueError with a message naming the balance, else self.balance = self.balance - amount. Both return None, because both CHANGE the object, and Python's convention is that a mutating call returns nothing. Returning the new balance is defensible and must then be documented.

c) After deposit(50) the balance is 150. After withdraw(30) it is 120. withdraw(200) raises ValueError and the balance stays at 120: the check happens BEFORE the subtraction, so a refused operation leaves the object exactly as it was. That last point is the invariant doing its work, and it is what makes the class safe to call from code that does not check anything itself.

d) A float cannot hold most decimal amounts exactly, so a long series of deposits and withdrawals drifts, and two balances that should be equal compare as different, exactly as in the very first set. The standard repair is to store CENTS as an integer, and to divide by 100 only when displaying. The alternative is the decimal module, which is what real financial code uses.

e) It got past because the attribute is public and Python has no way to intercept a plain assignment unless the class asks for one. The two levels of answer: by convention, name it self._balance and provide a read only accessor, which tells every reader that assigning to it is a breach; by mechanism, use a property, which lets the class run code on assignment and raise. In COMP 202 the convention is the expected answer, and knowing that the mechanism exists is worth a sentence.

a) students = [Student('Ana'), Student('Ben'), Student('Chen')], with the marks added afterwards through add_mark, then for s in students: print(s.name). Note that printing s itself would use __str__ and show the whole line, which is usually what a report wants; s.name is the version that says only the name.

b) sorted(students, key=lambda s: s.average(), reverse=True). It returns a NEW list holding the same objects in a different order: the objects are not copied, so a change made through one list is visible through the other, which is right, since there is only one Ana. students.sort(key=...) reorders the list in place instead and returns None, exactly as in the structures set.

c) sum([s.average() for s in students]) / len(students), with the guard if students == []: before it, since an empty list would give ZeroDivisionError. There is a second guard hiding here: a student with no marks returns None from average, and None cannot be summed, so either the class returns 0 for an empty student or the comprehension filters those out. Deciding that in one place is precisely what the class is for.

d) mean = the class average, then [s for s in students if s.average() > mean]. It costs TWO passes, one to compute the mean and one to select, and that is unavoidable: nothing can be compared to the mean before the mean is known. It is worth stating because the instinct is to try to do it in one pass, and the honest answer is that a two pass algorithm is the right one here.

e) First, that every student has the same fields, because __init__ creates them all: a dictionary of records grows a field the day someone writes a new key by mistake, and the typo creates it silently. Second, that the values are valid, because add_mark refuses anything outside the range, whereas nothing stops a dictionary from receiving a mark of 130. A third, in passing: the class gives the objects a printed form and an equality, which a raw dictionary can only imitate.

a) False. It is an ordinary parameter name, and the only rule is that it is the FIRST parameter of a method, filled in by Python with the object to the left of the dot. The counterexample: a method written def average(this): works exactly like one written with self, and Python says nothing. Correct version: self is a universal convention, worth following without exception, and it is not enforced by the language.

b) False. An attribute in the class body is created ONCE, for the class, and shared by every object. The counterexample: with marks = [] in the class body, ana.marks.append(8) makes ben.marks show 8 as well. Correct version: per object state goes in __init__ with self; the class body is for constants and counters shared by the kind.

c) False by default. Without __eq__, the equality sign compares identity, so two objects built separately are different whatever they hold. The counterexample: Student('Ana') == Student('Ana') is False. Correct version: define __eq__ to say which attributes make two objects equal, and only then does the equality sign, and with it the in operator, answer on the values.

d) False. __str__ RETURNS a string and prints nothing; print is what prints, using the returned string. The counterexample: a __str__ that calls print instead of returning makes print(obj) show the text at the wrong moment and then raise TypeError, __str__ returned non-string. Correct version: __str__ returns the text, print displays it.

e) False, and it is the point of inheriting. A subclass has every method of its parent without writing anything, and it redefines only the ones whose behaviour must change. The counterexample: a SavingsAccount that defines only add_interest can still be deposited into and withdrawn from. Correct version: a subclass inherits everything and overrides what it needs, calling the parent's version with super when it wants to extend rather than replace.

a) class Course: then def __init__(self, title): with self.title = title and self.students = [], then def add_student(self, student): self.students.append(student). The list is created per object, inside __init__, for the reason of exercise 2 c). Note that add_student takes a Student OBJECT, not a name: building the student is the caller's job, and a course that built its own students would be doing two jobs.

b) def average(self): if self.students == []: return None, then return sum([s.average() for s in self.students]) / len(self.students). The Student computes its own average, since it is the only class that knows its marks; the Course averages those numbers, since it is the only one that knows its students. Each class answers about what it holds, and nothing reaches through the other's state to recompute what that class already provides.

c) def best(self): if self.students == []: return None, then return max(self.students, key=lambda s: s.average()).name. On an empty course it returns None, which is the honest answer, and the caller has to handle it; raising a ValueError would also be defensible and must be documented. Note that max on an empty sequence raises by itself, so the guard is not decoration.

d) It breaks the guarantee of the Student class: the validation that refuses a mark of 130 lives in Student.add_mark, and a Course that appends directly walks around it. It also ties the two classes together, so that a change to how a Student stores its marks breaks the Course. The repair is one word, call the method: student.add_mark(x). A class should talk to the objects it holds through their methods, exactly as an outside caller does.

e) def __str__(self): lines = [self.title] then for s in self.students: lines.append(' ' + str(s)), then return the pieces joined with newlines. It calls str on each student, which calls Student.__str__: the course describes itself by asking each part to describe itself. That is composition in one line of code, and it is why adding a field to a Student changes the course report with nothing to edit in Course.

a) class SavingsAccount(Account): then def __init__(self, owner, balance=0, rate=0.02): with the parent's initialisation and self.rate = rate; then def add_interest(self): self.balance = self.balance * (1 + self.rate). deposit, withdraw and __str__ are not written at all, and they work, because the child has everything the parent defined.

b) super().__init__(owner, balance), as the first line of the child's __init__. Without it the parent's initialisation never runs, so self.owner and self.balance are never created, and the first call to deposit raises AttributeError, SavingsAccount object has no attribute balance. Copying the two assignments into the child instead of calling super also works and duplicates the validation, which is the same argument as the average written twice in the functions set.

c) The child's version runs for a SavingsAccount and the parent's for an Account: Python looks for the method on the object's own class first, and only then on its parent. That is what overriding means. A child that wants to EXTEND rather than replace calls the parent's version inside its own with super().__str__(), and adds to it.

d) After add_interest the balance is $1000 \times 1{,}02 = 1020$ dollars. After withdraw(500) it is 520 dollars, and the withdrawal is checked by the PARENT's method, which the child inherited unchanged, so the guarantee that the balance never goes negative still holds for the child. Inheriting an invariant along with the methods is the real benefit here.

e) The test fails: a Course is not a Student, and no code that expects a Student would work if handed a Course. Sharing two attribute names is not a reason to inherit; it is a coincidence of vocabulary. The right relation is the one of exercise 9, composition: a Course HAS a list of Students. The rule to carry away is that inheritance is for IS A, composition is for HAS A, and when in doubt in a first course, composition is almost always the correct answer.