You made it back! Congratulations. The first week is a bit frantic, this week is going to start talking a lot more about ideas and less about setting up accounts.

Remember to read up on the Holy Wars assignment.

The Lab! :microscope:

This week we’re going to do as much of the homework as we can in the lab. That’ll give you some insight into how we think when we’re writing code, and how to break down the problem in a way that you can actually fix it.

This week’s folder has three exercise files. You should start at 1 and then do 2, and then… do 3!

When you make a test pass, make a git commit. This level of granularity will help you recover from mistakes in the future.


Code is complicated, and you need to be able to understand large amounts of it in small amounts of time! If it is formatted consistently, then you don’t need to use brain cycles to understand what’s going on.

Git tracks all changes, regardless of their importance. If everyone on the team obeys the linter’s rules then there should be very few diffs with low demantic value.

Exceptions should be made in the real world. If you want to line some things up to make their meaning clearer, then you should! However for these first few weeks, your work will be auto marked, so if it’s not 100% perfect according to the linter then it won’t pass that test.

Exercise 1 is all about linting. There is some code that is perfectly fine from python’s point of view, but remember:

Programs must be written for people to read, and only incidentally for machines to execute.

Abelson & Sussman, Structure and Interpretation of Computer Programs (SICP), preface to the first edition

We are using the flake 8 linter and the docstring plugin. It’s very strict. In the real world you’d probably be more permissive, but it’s best to learn the rules so that you know when you are breaking them.

The best way to learn about how to satisfy it is to just fix the errors 1 at a time.

Some errors and warnings generated by flake 8 in Atom

If you click on the line number on the right of each error it’ll take you to that error. It gets really quick once you are into it, but it’s a real pain to learn. (Sorry!)

Set to, and see how you go. Ask if you get stuck, the odds are that someone else is stuck there too.


Exercise 2 is about fixing syntax errors. The file is riddled with mistakes and your job is to correct them all. This is going to be really painful, but it’s a task that you’ll be glad you did when you get out there into the wild.

I’d start by looking at the syntax highlighting. Why isn’t it pretty colours? Then I’d fix obvious linting errors, that should fix a few more things. Then I’d run the code—you do that by pressing ctrl+shift+b—and that will at least tell you roughly where the first error is.

This exercises is going to be like picking broken glass out of your dinner!

It’s worth noting that python often points out an error a while after the error actually happens. It’s a bit like if your steering breaks in your car, you won’t crash until you get to a corner. It’s not a problem on a straight road.

Again, ask for help, for everyone’s sake!

Testing Functions

We talked about red, green, refactor in the lecture. This is your chance to see it in action. You won’t actually we writing any tests, but this is the first time you’ll really be leaning on your tests to help you through the week.

To get started, open a terminal, cd into your code1161base directory, and let’s get started:

[email protected]:~/code1161base$ python week2/

When you press enter it’ll pause for a moment, and then spew hatred onto the screen. All but one test fails. One is green but that’s because the file is waiting for you to fill it in. Don’t panic, it’s supposed to spew hatred, it’s your job to sooth it and make it tame and green.

Keep this terminal window open while you work. Whenever you think you’ve got something working then run the tests. Every time you make a test pass, commit your code.

Writing Flow control & Loops is a whole load of function. They are all empty except the last. They are what we call stubs. The last one is a helper function to give you an idea of what some of the later functions are returning.

ctrl+shift+b will run the code and that’ll give you slightly quicker feedback than the full test suite will give you.

Your job is to read the docstring on each function and then fill out the body of the function so that it returns what is asked for.

def my_function():
    """This is a docstring.
    It explains what the function does, or in this case, should do.
    #this is the body of the function
    pass  # this is just a keyword that tells python not to do anything

This is going to take a while, but each function builds on the previous one. Keep chipping away, making notes in your lab book, talking to your neighbours and asking us. By the end of this exercise you’ll actually be pretty good programmers!

This week’s reading :books:

Shaw, Z. A. (2013). Appendix A: Command Line Crash Course. Do as much of this tutorial as you can. It’ll cement what you’ve learned already.

Victor, B. (2011). Up and Down the Ladder of Abstraction.

Doherty, B. (2016). A thinking trick for beginner programmers - Ghetto TDD

This week’s homework

There are some files in the week 2 folder in GitHub. Work your way through the exercises until all the tests pass. Each time a new test passes, make a commit. Then when all tests pass, or when you give up, push to your repo. This will be the first time you’ve done this, so leave plenty of time before the 7pm cut off on Thursday. This is a hard deadline, so don’t miss it.

Do these tutorials to really ram this stuff into your brain. Top tip, do them before doing the exercise files, it’ll make life much easier.

It’ll go over the same stuff we’ve already done, but it’ll be phrased in a slightly different way, that should deepen your understanding. The better you understand this really foundational stuff, the easier everything else will be.

You might also like to play these games too:


These videos explain how to do each of week 2’s exercises. You should really try to solve the problems yourself before you watch the videos.