Our diagramming conventions follow the Spring lecture notes, but this page is a nice go-to reference for homework and studying.

Variables

A diagram for a variable should include the variable name and a box for the value. Here is a diagram for the variable b, currently holding the integer 2:

variable box

When we reassign a variable, we cross out the old value and replace it with the new value. The old value should still be legible. For example, if we reassign b to 3.5 we get:

variable change

If the variable changes value multiple times, the box should show the full history of all of the values of that variable. For example:

variable value changes multiple times

When writing the value, make sure it is unambiguous what the value is, and what type it is. Write floats with a decimal point or in scientific notation, write strings with quotes around them, and so on.

Objects

A object is an instance of a class. While there is only one class Point3, there may be more than one Point3 object. Each time you call a constructor, you create a new object.

When you diagram an object folder you should obey the following conventions:

- The folder's identifier (id) should be unique and go on the folder tab.
- The class (type) of the object should go at the top right of the folder.
- The attributes should be listed inside the folder and diagrammed just like variables.

For example, a folder for an object of the type Point3 (introduced during lecture) might look like this:

components of an object's folder

We do not draw object folders for basic types like int, float, bool, and str. (For these, we use the Variables conventions above.)

Function Calls

Call frames are the way we diagram the temporary workspace for variables used during a function call. Diagrams of call frames should obey the following conventions:

- The top left corner is a box with the function name.
- The top right is the instruction counter (sometimes called program counter), the next line of code to execute.
- The instruction counter should start at the first line of executable code in the body. (This means the first line is not the line beginning def function_name(): but rather the first indented and executable line of code inside the function.)
- We draw parameters with their value boxes partially poking out of the left side of the call frame (to indicate that the value is entering the call frame as an input to the function). It is not necessary for you to draw it this way. But parameters must be completely or partially inside the call frame.
- Local variables are drawn completely inside the call frame.
- Local variables are not added until their assignment statement finishes executing. (This matters if we ever ask you to draw up until a particular line of code where perhaps the right hand side (RHS) has been evaluated but the LHS has not yet been assigned.)
- We draw return values with their value boxes partially poking out of the right side of the call frame (to indicate that the value is exiting the call frame as an output of the function). It is not necessary for you to draw it this way. Return values must be completely or partially inside the call frame. If the function does not explicitly return anything, you must still draw a Return variable whose value is None.

See the lecture notes for more details on how to create a call frame at the start of a call. We will always number the lines of code for you.

For example, suppose we have the procedure:

example function print_name

If we execute the call print_name("Donlon","Mary"), then the call frame and Program output box should be drawn as follows:

call frame with program output

If the function call has completed, draw a single line through it. This lets us know what was executed but also indicates that the function is no longer actively being executed. If we were to ask you to draw up to a particular a line number (say, up to line 4) then the call frame should not have a line through it.

Print Statements

Notice in the above example that the print statement prints to the Program output box. If you are asked to diagram code with print statements, make sure to include a Program Output box that depicts what is printed during the execution of the code.

Frames and Global Space

Remember that you can use a function call as an expression. The call evaluates to the result of the return statement (or None if there is no return statement). If this call is used in an assignment statement, this will copy from the RETURN variable to another place in memory (such as to a global variable). For example, the call y = to_centigrade(212.0)will copy the final result (100.0) into the global variable y.

Things in the Global and Heap Space that We Do Not Draw, Despite What Python Tutor does

The global space contains variables for anything defined and directly accessible. We do not draw all of them because it would be too tedious. We'll list them here so you are clear on what is and what is not expected of your diagrams. We do not draw global variables for:

- Built-in functions like len or print. Not even the Python Tutor shows these.
  - Also: do not draw call frames for built-in functions.
- Any module that you import. This includes built-in modules like the math module and modules that you may have defined in a file, for example, importing shapes from the local file shapes.py. The Python Tutor draws these, but you should not.
- Any function that you define. The Python Tutor draws these, but you should not.
- Any class that you define. The Python Tutor draws these, but you should not.

The heap space contains folders for any initialized objects. We do not draw all of them because it would be too tedious. We'll list them here so you are clear on what is and what is not expected of your diagrams. We do not draw folders on the heap for:

- Any modules that you import. The Python Tutor draws these, but you should not. Note: sometimes in lecture we might draw the variable for the module and the module itself in order to explain how to refer to attributes and functions inside modules (for example, math.pi or math.abs()). But you should now draw these elements when you are diagramming python execution.
- Any function that you define. The Python Tutor draws these, but you should not.

example full diagram

------------------------------ if you are working on A2 or studying for Prelim 1, you can stop reading here ----------------------------

Note: after we have covered how to do so in lecture, you should draw the Class Folder itself on the Heap, including all class attributes and class methods. But you still do not draw the global variable that contains the identifier of the class folder (shown in purple above). You will be expected to know how to draw Class Folders in A5, Prelim 2 and the Final Exam.

Class Folders

When you define a class, Python creates a special folder called a class folder that stores the information about that class. (As we just mentioned, Python also creates a global variable with the same name as the class and puts the name of that folder in the global variable, but we do not want you to show that variable in global space.) We just want you create a folder on the heap, and put the name of the class in the tab. We also want you to put the tab on the right so that we can tell this is a class folder. This is illustrated below:

class folder

The class folder contains all the methods and any class attributes. In a class definition, any assignment statement outside of a method definition creates a class attribute. In the example above, CONST is a class attribute.

Technically, the methods are also variables themselves. This is what you would see if you used the Python visualizer. However, the contents of this variable are really complicated, and the Python visualizer just writes the method header (the name plus all of its parameters) as its value. Therefore, that is what we want you to write for the methods in a class: the method header (without the def).

Method Calls

A method call works almost exactly like a function call. You create the call frame, and plug the arguments into the parameters. You then execute each line in the method, changing the call frame as necessary. Finally, you erase the frame.

The only real difference is the function name that goes in the upper left box. We want both the name of the class and the method name in this box. For example. for the method call

e.foo()

the initial diagram for the call frame is as follows:

call frame for method

Note the name is not foo in the top left folder, but Example.foo. That tells us to use the version of foo that is stored in the class folder Example.

Constructor Calls

A constructor is just a function, so Python should create a call frame when it is called. However, this function is built-in, so we do not really know what it looks like. You will notice that the Python Tutor does not create a call frame for the constructor. It does create a call frame for the initializer __init__, which the constructor uses as a helper. Similarly, we will not draw a call frame for the constructor but we will draw one for the __init__ method. The first parameter, self, should have the value of the identifier of the empty object folder that is created by the constructor, but populated by the __init__ method.

If we execute the following assignment statement,

e = Example()

The resulting diagram would be as follows:

init call frame

------------------------------ if you are working on A5 or studying for Prelim 2, you can stop reading here ----------------------------

Inheritance

After we have covered inheritance in lecture, the following applies.

When a class inherits from another class, we indicate this relationship in our class folders. we put the name of the parent class in parentheses, as shown below.

Note that this class has no methods or class attributes in it, because there are none in the class definition.

You will be expected to know how to indicate inheritance in the tab on the right (as shown above) for the Final Exam.