Task 4 - Banking at Goldman Stanley
Background
Welcome to Goldman Stanley, a fictional elite investment bank with a reputation for precision and reliability. You, a recent hire on the TMT (Technology, Media, and Telecom) team. As part of your onboarding, you're being asked to assist with a critical internal tool that tracks simple transactions between internal department budgets.
Your manager David wants to ensure that the banking logic is airtight meaning no accidental overdrafts, no incorrect transfers, and absolutely no bugs. To make this happen, you’ll need to write Python code that combines assertions to catch logic errors early and defensive programming to guard against bad input.
This is your first step toward earning the team's trust and maybe even that invite to the Friday rooftop drinks.
In real-world software, especially in systems like banking, robustness and correctness are critical. Two key tools developers use to build reliable code are:
· Assertions: Internal checks that validate assumptions made by the programmer (e.g., "This variable should never be negative"). Assertions are mainly used during development and debugging.
· Defensive programming: Validates inputs and usage patterns to prevent invalid or unexpected behaviour at runtime. This includes checking for correct types, value ranges, and providing helpful error messages when something goes wrong.
Description
In this task we will be using custom errors as python will already raise some of these errors when we execute invalid code. Our new errors are located in cusom_errors.py. You must use these custom errors, please see rubric for related penalties in this task.
You are designing a Python class that represents a basic bank account system. The system must allow:
· Creating accounts with an owner name and an initial balance.
· Depositing money.
· Withdrawing money.
· Transferring funds between accounts.
· Restricting users.
You must ensure that this system is:
· Correct: Through use of assert to validate assumptions in your logic.
· Safe: Through defensive programming techniques that prevent invalid inputs (e.g. wrong types, negative amounts).
Requirements
Functionality for the BankAccount class:
· Each account has an owner (a string) and a non-negative starting balance (float or int) and an account ID (a int).
· Users can deposit, withdraw, and transfer funds.
· Account ID is a unique number associated with each account. Each account should have an account number should proceed the previous by 1. Account numbers start from 1045.
· Every user at Goldman Stanley is gifted $49.99 upon opening their account.
o Morgan Stanley will likely build upon this codebase later on and introduce other subclasses of BankAccount for their other financial products that may offer different opening bonuses.
To facilitate this you will need minimally the below listed methods and a class itself called BankAccount as well as it's constructor.
set_next_account_number(cls, next_account_number:int) -> None
In testing your code you will need to create many instance of bank accounts, quite often in your testing it will be useful to reset / update what the next account number is. You can assume this method will be called before each unit test. e.g BankAccount.set_next_account_number(1045)
1. Set's the account number for the next account that will be created.
2. Method is a class method.
You can assume if this method is called then you can ignore previous instances.
ban_account(self, reason: str) -> None
· This method is used to flag an account as banned (e.g., due to suspicious activity or internal audit findings).
· Once banned, the user cannot deposit, withdraw, or transfer funds.
· All affected methods should check whether the account is banned and raise an error if any operation is attempted.
· All banned users have their account number stored within BankAccount.banned_accounts .
· A reason is always provided however maybe an empty string.
o This method is demonstrated in the string example below.
Update 20/05/2025:
As this behaviour was not initially defined in the spec we will accept a reasonable interpretation as to not invalidate past attempts see following:
Calling the ban_account method on an already banned account you have the choice of:
· Not raising an error, but updating the reason to be the new reason.
· Raising a relevant error.
unban_all(cls) -> None
· After this method is called all accounts are no longer banned. Similar to set_next_account_number you can assume this method will be called before each test and is also a class method.
deposit(self, amount: float | int) -> None
· Adds a specified non-negative amount to the account balance.
withdraw(self, amount: float | int) -> None
· Deducts a specified non-negative amount from the account balance if sufficient funds are available.
transfer_to(self, target_account: "BankAccount", amount: float | int) -> None
· Transfers a non-negative amount to another valid BankAccount instance, provided enough funds exist.
set_transaction_limit(self, limit: float | int) -> None
· Allows the account to specify a maximum transaction amount for withdrawals or transfers.
· Withdrawals or transfers that exceed this limit, even if funds are available, should not proceed.
· By default an account's limit is None.
is_banned(self) -> bool
1. Returns True if the account is banned and False if the account is not banned.
__str__(self) -> str
Please follow the code snippet below for the correct formatting for the BankAccount's string method:
Python