October 4th, 2020
Written by Brahm Capoor and Juliette Woodrow
This week's section consists of a somewhat disparate set of topics: parameters & return values, lists, Image algorithms, and debugging with doctests. Each of these topics is worthy of focus, and I trust you to decide what's best for your section.
Students would have touched on this by your section last week, but we delved into this topic in a lot more detail since then. Students should hopefully be at least somewhat familiar with these ideas because it was tested on the diagnostic, but this is a notoriously difficult idea to intuit so here are a few points you might find helpful:
in_range in this section) and drawing
thick borders around each stack frame can help reinforce the
separation between functions.
Equally, students might be confused about the types of parameters and return values: does a function need to return the same type as its parameters? Are either parameters or return values necessay? Here's the metaphor I used to clarify this, in case you find it helpful:
Suppose I'm a function, and my job is to decorate a room. If I'm a good decorator, I can do that without asking for your opinion. I'll go into the room, hang up some paintings, put down a few potted plants and maybe a curtain or two. If I'm a really good decorator, I'll get your input: who your favorite artists are, how many plants you want, and so on: perhaps even an upfront payment.
Once I'm done decorating, I'll leave the room. If I'm a good decorator, I'll describe how nice the room looks to you or maybe give you a receipt, and if I'm a bad decorator, I'll yeet myself out without saying anything to you.
In this example, the input you provide my function before I go into the room are the parameters. If I don't need any input from you, I don't have any parameters. You don't know what I'm doing once I'm inside the room, but the thing I give you back once I'm done decorating is a return value. If I leave without saying anything to you, I didn't return anything. Note that my parameters and my return values don't have any relationship: whether or not I need your input prior to decorating has nothing to do with whether I tell you something when I'm done.
This metaphor is also helpful for students who are confused about the difference between parameters and return values. You can describe the act of decorating the room like printing - just because I've slapped a painting on the wall in another room doesn't mean you can now see it. I need to explicitly give you that painting--or a copy of it--so you know what it looks like.
Similar to ArrayLists in Java, lists in Python are
variable-length ordered collections, with the nuance that they can
store objects of any type (i.e. they're not homogenous). This week,
we'll mostly be focussing on the following use cases:
>>> lst = [] # make a new list
>>> lst.append("arthur") # add a new value
>>> lst.append("hitchhiker")
>>> lst.append("deepthought")
>>> lst[2]
"deepthought" # lists are 0-indexed
>>> len(list)
3 # number of elements in the list
>>> for i in range(len(list)):
... print(lst[i])
arthur
hitchhiker
deepthought
We also introduced the Python console, an interactive environment for evaluating the results of different snippets of code. Check out the first few slides of this lecture for more details on how to use it.
Finally, we introduced doctests as a way of sanity checking the behaviour of our functions. The syntax for a doctest is the following:
def adds_two_numbers(n1, n2):
"""
>>> adds_two_numbers(5, 5)
10
>>> adds_two_numbers(1-, 1)
0
"""
return n1 + n2
Doctests are pretty picky about formatting. Make sure there's a
space between the >>>
and the name of the function. To run a doctest, you can
right-click on it in PyCharm and select 'Run Doctest', but you can
also type this in the terminal:
python3 -m doctest -v filename.py
replacing python3 with py on Windows
computer. The right-click method is finicky, but the terminal
version should always work. Importantly, doctests will only work
if the entire file has no syntax errors. Otherwise, you'll see an
error message saying no tests were found.
In Friday's class, we discussed the
SimpleImage library, which allows a programmer to
quickly and easily work with images. The best resource to
familiarize yourself with this library is our
Image Reference handout
, which has already been released to students. We used images as a
way of motivating nested loops, and introducing
object.method syntax to students.
Like I said above, this section is mostly yours to play. If your students are feeling shaky on parameters and return values, focussing on the first section is probably a good idea. If they're feeling good about them, you might want to consider doing the image problems instead. I'd recommend you tell students to take a look at the debugging with doctests problem in their own time, but not spend any time on it in section.
In Range: In writing the function, focus on the fact that
parameters and return values needn't have the same value. In
writing main, focus on how you can leverage the same
variables in different permutations as parameters to emphasize the
separation of scopes between two functions.
Fizzbuzz: In writing the function, focus on how you can do
math on a parameter whose value you don't know. In writing
main, focus on how you can leverage having
differently-named variables in different functions.
Test Simulator: This is kind of a neat program in which you show that medical test accuracy rates can be deceiving. The logic here is a little tricky, so it's worth working through what variables need to be created and where.
List Problems: These can be good problems if your students are feeling iffy on lists. Focus on the different ways you can loop over a list and when it makes sen
Image Problems: Focus on coordinate math, why a nested loop is necessary, and when we need to create a new image versus just manipulating the original one.
Doctests: This can be helpful to go over with students if you have time. It will help them better debug their assignments. Reach out if you have questions about doctests.