Spring 2010»CSCI 470 Homework 2

CSCI 470 Homework 2

Assigned Date: Tuesday, Feb. 16, 2010
Due Date: Thursday, Feb. 25, 2010
Due Time: 1:30pm

Last modified on February 22, 2010, at 12:29 PM (see updates)


This assignment focuses on:

  • programming style and documentation,
  • writing elegant Python code, and
  • unit testing.

This is a pair-programming assignment (i.e., you may work with one partner). You may discuss the assignment only with your partner or the instructor.


Complete the following recursive function definitions:

  1. def member(item, aList) -- returns True if item is in aList, False otherwise
  2. def myLength(aList) -- returns the length of aList
  3. def myReverse(aList) -- returns aList reversed
  4. def myMap(function, aList) -- applies function to the each element of aList. You may assume that function is unary (i.e., it expects a single argument).
  5. def myFilter(function, aList) -- similar to Python's filter().
  6. def myReduce(function, aList) -- similar to Python's reduce(). Accordingly, it should raise a TypeError, if called with an empty sequence. You may assume that function is binary (i.e., it expects only two arguments).
  7. def mapBoolean(aList) -- returns a list of boolean values, where each boolean is the truth value of the corresponding aList element.
  8. def countItem(item, aListOfLists) -- returns a count of how many times item appears in aListOfLists, regardless of list level (i.e., how deeply embedded it is).
    • The following code example may be of use:
>>> from types import ListType
>>> isinstance([1, 2, 3, 4], ListType)
>>> isinstance("hello", ListType)


  1. You may define helper functions, e.g., head(), tail(), if you wish.
  2. You must use the above function headers exactly.
  3. You may not use the corresponding Python functions inside your function definitions (e.g., no use of len() in myLength()).


Follow the Golden Rule of Style: "A program should be as easy for a human being to read and understand as it is for a computer to execute." [1]

In general, you should comment any variable, obscure statement, block of code, method, and class you create.

Your comments should express why something is being done, as opposed to how the how is shown by the code.

Unit Test Documentation

Each unit (e.g., function, class, etc.) should start with a doc string. This comment should follow the doctest style, since it allows to:

  • check that a module's docstrings are up-to-date;
  • perform unit and regression testing; and
  • write tutorial documentation, illustrated with input-output examples (i.e., "literate testing").

Top Documentation

In this course, you should always include opening comments as follows:

#   Author:     <Your Name(s)>
#   Email:      <Your email address(es)>
#   Class:      CSCI 470, Section 1
#   Assignment: HMWK2
#   Due Date:   <The assignment's due date>
#   Certification of Authenticity <remove one of the following>:     
#      I certify that this lab is entirely my own work.
#      I certify that this lab is my own work, but I received
#      some assistance from:  <Name(s)>
#   Purpose: <Provide a simple, yet complete description of the task being
#         performed by this program. It may be several sentences long.>
#   Input: <Provide a simple, yet complete description of the input required
#               by this program.>
#   Output: <Provide a simple, yet complete description of the output generated
#          by this program.>


  1. Submit your source code, recursion.py, on WebCT by the due date.


Your grade will be based on how well you followed the above instructions, and the depth/quality of your work.


  1. Cooper, D. and Clancy, M. (1985) "Oh! Pascal", 2nd ed., W.W. Norton & Company, New York, p. 42.