_A3.1

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 4

A3.

1 - The Runner's Assertion

Make sure that all functions are in the file they need to be in, with appropriate function
names and arguments.

You are ONLY allowed to use the following external modules: csv, math, typing, abc,
unittest. Using any other external module apart from these will result in a score of 0 for

that task. (NOTE - You may not need all of these modules)

Please note that using an unapproved external module will result in deductions of upto the entire approach and
test marks for that particular task.

Documentation
In this assignment, documentation will be marked. You are required to complete the
following parts of documentation:

1. A well-versed concise and informative docstring. You may use any documentation
standard for the docstring. A docstring needs to be present for ALL FUNCTIONS,
METHODS AND CLASSES that you are writing or editing. A docstring is not required for
functions that you did not write.

2. Clear type hinting for all functions and variables.

In-line comments and Variable Naming


You are expected to use in-line comments throughout your program to make sure it is clear
to the reader. The amount of comments necessary depends on how clear the code is by
itself. Therefore, a good habit is to write clear code, so that the amount of in-line comments
required is reduced. This will also reduce the number of bugs created.
Comment your code as you write it rather than after reaching a final solution, as it is a lot
easier to remember why certain decisions were made and the thought process behind them
when the code is fresh in your mind.

Ensure your variable names are meaningful and concise so that your code is
understandable at first read. When a reader is going through your program, it should read
like a self-explanatory story, using in-line comments to explain the logic behind blocks of
code and any additional information that is relevant to the functionality of the code.

You will be marked on your commenting and variable naming in this assignment as you have come to terms
with Python.

Avoid repeating yourself by commenting on lines of code that are fairly self-explanatory, and
instead reserve your comments to explain higher-level logic, such as explaining the overall
purpose behind a small block of code.

Skeleton/Starter Code:

● Tasks will start with some skeleton/starter code for each function.
● Make sure function and variable names match what is listed in the task; these will be
needed to pass automated tests.

Please note the following points about the assignment that you are beginning:

PLEASE NOTE - This assignment's tasks demonstrate that the given scaffold and tests are INCOMPLETE!
If you open any of the tasks and the scaffold given, even run the given tests (using the 'Check' button) you
can see that the given code passes all the test cases! Does that mean the assignment is complete? No! You
need to work on it and make further tests to ensure the correctness and validity of your code.

1. The functions/methods given to you in the scaffold need to have the names that they
have been given. Please don't change this. All the effort has been made to create these
functions/methods with the arguments each will need. You should not add or remove any
more arguments to/from these functions/methods.
2. You can and are STRONGLY recommended to create more functions/methods in all the
tasks to break down your work. This will improve your code by introducing modularity and
reducing repeatability. This is one of the things you are being marked on for this assignment
so ensure that you do this properly!

3. You should NOT ask the user to provide any input in this assignment. Any input functions
that are required for any of the tasks have already been done for you. You may use these
but please don't get the user to input anything in any of your functions as you will get an
EOF error.
4. You are NOT ALLOWED to use any external modules in this assignment except csv,
math, typing, abc, unittest.

5. You are strongly recommended to read and solve all of your pre-class activities before
attempting the assignment. All the knowledge required to solve this assignment is either in
the pre-class, the workshop, the applied, or the description of this assignment.

7. From Tasks 1 to 3, the use of Try Except statements is BANNED. You should use Try
and Except ONLY IN TASK 4.

Custom Errors
YOUR RESPONSIBILITY to ensure that a proper error is raised when an invalid input is
received. Here are some pointers:

● If the value received by a method is invalid or not what the method expects, then you
should raise a CustomValueError
● If the type of value received by a method is invalid or not what the method expects,
then you should raise a CustomTypeError
● If the value being passed to the method is not an attribute of the class, then you
should raise an CustomAttributeError
● If the method is trying to get a value from a dictionary that shouldn't be returned, you
should raise a CustomKeyError
These errors have been imported for you in the scaffold for each task already, you merely
need to raise them. However, please include a helpful string for the user to figure out what
error they have made.

There are a few other errors introduced in the tasks that you need to raise on specific
conditions.

For example -

def func_that_adds_numbers(a: int, b: int) -> int:


if not isinstance(a, int):
raise CustomTypeError("wrong input") # This is not very helpful

if not isinstance(b, int):


# This is a lot better!
raise CustomTypeError(f"Incorrect input type for b, expected int got {type(b)} instead")

return a + b

Your approach marks in every task contain marks for how descriptive your error strings are
so please ensure to add these.

All of these errors have been defined in the custom_errors.py file available in each task.
You may or may not need to use all of these errors.

You might also like