Question: I ask this question because when a loop is debugged with repeated print statements, it slows down the program much more that I would have originally expected. I have gotten used to this, but now I am curious as to the technical reasons why this would be the case? It seems to me that the various calculations and assignings of variables would be more expensive than outputting strings.

Answer: 
A huge, huge, ***huge*** number, especially if the output is visible on screen, such as in a terminal emulator window on a modern multitasking system.

Firstly, if you’re outputting numbers in decimal, there’s a divmod for each digit, which is a relatively expensive operation compared to, say, adding. (If you output in hexadecimal, it can be a bit cheaper, as each digit can be extracted using shifting and masking only.) If you output floats, there’s some more calculation involved; with dates and times, there’s months of various lengths, leap years, leap seconds, DST, and timezones all to be considered.

But that’s all just calculation and logic, so it’s dwarfed by what’s to come.

Next Python has to send the output text to the terminal for display, which means the operating system has to step in to transfer the data through a buffer, then wake up the other process. The terminal process scans its input for control sequences to move the cursor or change colours. Then a text renderer scans the text for characters that need special handling: maybe there’s some combining accents to be applied, or some right-to-left script that needs to be rearranged for display.

Once the text is laid out, the terminal tells the window manager which area of its window needs to be redrawn, and the window manager checks whether it’s visible – it might be minimized or hidden behind another window. The terminal is told which area actually needs painting, and finally draws the text, in its proper font and colours, kerning and antialiasing. Does the window have a cool-looking transparent background? That has to be merged in too.

Depending on the windowing system, the pixels could then go on another trip through operating system buffers to a compositing manager, which actually draws the window contents onto the screen, taking into account window transparency.

FInally, the pixels arrive on screen, where they barely have time to be seen before being swept away by their millions of successors, as you watch the output streaming past far too fast to read.

It’s amazing how much work our computers do for us.
This is not a matter of CPU instructions, at least not the CPU instructions in your Python program. When you do a `print` with a terminal emulator (command window) as output, the string to be printed is copied into a kernel buffer, then to the terminal process's memory. The overhead is in the context switching (both processes doing system calls, i.e. jumping into kernel mode) and the copying of the string in memory.