Warmup

Part A: Department Bank Accounts

In bank.py, you’ll find an implementation of a BankAccount class. The class is relatively simple: there is a class owner and a current account balance. There is also the ability to specify the type of account (e.g. Checking or Savings). The class writer has documented what each method should do in a docstring.

They also worked on testing the class functionality in main(). However, there are a lot of bugs –at least five of them!– throughout both the class implementation and the test code. Note: if the same mistake exists twice you can count them as separate mistakes.

Your job: help out the class writer by fixing both the implementation and the test code! Make sure to document the fixes in WARMUP.md.

The storyline for what should be happening in the main function is as follows:

• There is a CS bank account made with $1500 in it
• $100 is withdrawn from it
• There is a new bank account made for Psychology with $3000 in it
• The Psychology account gets $145 added to it
• There is a new (2nd) CS savings account that is made with $500 in it.
• The programmer realized their mistake and transferred the 2nd CS account to Data Science
• Data Science gets a deposit of $50
• The Data Science account gets changed from a savings account to a checking account
• CS and Data Science throw an ice Cream party together that costs $40
• At the end, CS should have an account balance of $1380 and Data Science should have a balance of $530

Part B: A Basic Move Class

This lab is all about using object-oriented programming for simulations. One of the two main simulations for the lab is of animal movement: animals tend to move in repetitive ways when they’re searching for food, which will be interesting to visualize. To make these movement simulations run, we will be designing several classes that coordinate the repetitive movement behavior by storing a sequence of moves and returning the next move with a method. Your task for this part of the warmup is to debug the RepeatMove class, which simulates some of the simplest movement behavior we’ll see.

For both this lab and Lab 8 you’ll be making use of Move classes. The simplest of the move classes is the RepeatMove class, which is currently defined in repeat.py.

An instance of the RepeatMove class will store a sequence of values, and whenever asked, will return the next value in the sequence. Each value in the sequence represents a possible movement direction. When it gets to the end of its sequence, it loops back to the beginning and starts over. In other words, a RepeatMove object has two attributes:

• self.moves contains the list of values that the RepeatMove will go through
• self.current contains the index of the element that the RepeatMove will return next time it is asked (this should start at 0)

The constructor for a RepeatMove object takes in one parameter moves, so that the user can specify what sequence of values (representing moves) the object should use.

A RepeatMove object has one method, next(), which returns the element of self.moves at index self.current. If self.moves is the empty list, next() should return None. When self.current reaches len(self.moves), self.current should be reset to 0. Otherwise, self.current should increment every time next() is called.

There is a single error in the class definition for RepeatMove that you need to identify! There are no errors in the test code in the main implementation. Remember to document the change in WARMUP.md.

The expected correct output should be:

None
None
None
None
None
None
None
None
None
None
1
2
3
4
5
1
2
3
4
5