Lab 1: Docker and PythonSpring 2022

This lab seeks to help introduce you to the Docker and VS Code development workflow that the course uses for most of its projects, as well as to help you avoid some pitfalls with the use of Python in Project 1. You will set up Docker for use, do some visual debugging, and track down a nasty bug that many past students have run into!

Setup

If you haven’t already, follow our Docker guide to learn how to set up Docker on your computer. This will be useful both for this lab as well as for Project 1.

To get the code for this lab, create a repo using the GitHub template. Make sure to make this repo private. Clone the repo onto your system, then open it in VS Code. If you successfully set up Docker, you should be greeted with a pop-up in the bottom right asking you to reopen the directory in the development container; do so now! After some time taken to build the container, you should be greeted with the lab file in a directory and a terminal connected to the container (as shown in the Docker guide). If you’re having trouble at this point, please come to office hours or put up a post on Piazza describing in as much detail as possible what is going wrong—having a working Docker installation is essential for the course (which is why we’re making sure that it works in this lab!).

Tasks

This lab contains three tasks, each of which will end up with changes to lab1.py.

Validation of Docker Installation

Open a terminal in the VS Code window, at which point you should be greeted with a prompt inside the container, such that running whoami outputs eecs388, as detailed in the Docker guide. Run the following command in the terminal, replacing uniqname with your uniqname:

echo -n 'uniqname' | cat - ~/.shhhh | openssl dgst -md5 -binary | xxd -p

This will generate a value that helps us verify that your installation is working properly. (For the curious: I wonder what is in ~/.shhhh!) You should receive a long string of hexadecimal characters in the output. Copy this string and replace the TODO on the line with openssl output: with it. Also replace the TODO on the line with uniqname: with your uniqname. In all, your window should appear similar to this (but you will have to actually run the command to see the output; no cheating!):

OpenSSL command execution

Visual Debugging

Using the Visual debugger in VS Code will likely be a great tool throughout the semester. Luckily, the Docker workflow allows it to come working with no extra steps on your end! Here, we’ll run through a quick example to get you up to speed with the interface.

First, open lab1.py and hit the debugging symbol on the left side of the window. Set a breakpoint on the line directly after s = secret() by hovering over the line and clicking the red circle. You should now see that the circle stays lit and that the line appears in the bottom left, indicating that a breakpoint is set. Confirm that the “lab1” target is selected in the drop-down menu in the top left, then hit the ▶️ button to begin debugging.

Setup for the visual debugger

You should see that the program stops on the breakpoint you just set. Examine the variables section on the left side of the window, which shows you the values of any variables in the program at this point. Under the “Locals” section, s now appears, which is the variable assigned directly before the line on which you set the breakpoint:

s appears in the "Locals" section

The secret class has a special method, __repr__, that changes how objects of the class are displayed in the debugger (as well as in other places, such as when the object is evaluated in interactive Python shells). It’s hard to see what this __repr__ method does by looking at its code, but by viewing the value of s in the debugger, it becomes quite clear! Follow the instructions that you see in the debugger (which is the section blurred out in the above image).

List Reference Semantics

Finally, you’ll be responsible for fixing a bug that has historically caught many students in Project 1. (We hope this will stop you from making the same mistake!) Examine the description of the square function according to its comment, then carefully consider the output you see when running $ python3 lab1.py. Is the function acting according to what it says it should be doing?

It appears that although the function promises not to mutate its nums parameter, the values inside a in main change after the function call. This is happening despite the fact that the function uses the out variable, which at first glance might appear to be a copy of nums. Something is fishy here…

Your final task for this lab is to fix the square function such that the values in a do not change after the function call, i.e. the values of a printed in the “before function call” and “after function call” lines are the same. We still would like the squared values to be present in b, however—this is after all the point of the function! You might need to do a bit of research into what is happening here, along with possible ways to fix it. (There are many ways to go about this; there’s no one right answer!) While this may seem daunting if this is your first introduction to Python, we think that this type of self-directed exploration best helps you to remember what you’ve done here when you need it later (which, trust us, you probably will!). Happy hacking!

Submission

Submit lab1.py to the Autograder by the deadline.