Week 3 · Session 1

Comments, Markdown, and Strings

Lab 1 questions & the parts of a repository that are not Python.

Four Errors You Have Probably Hit

Read the last line of the error first. It names the problem.

  • ValueError: invalid literal for int(): you gave int() something that is not a number, often a piece with a stray space in it
  • TypeError: can only concatenate str (not "int") to str: you joined a number onto a string. Convert first
  • ValueError: not enough values to unpack: the left side of mm, dd, yyyy = ... wants exactly three pieces and got a different number
  • KeyError: 0: get_anchor_day received a month of 0, so a placeholder above it was never replaced

Questions to Ask Your Own Program

Run through these in order before you ask anyone for help.

  • Does print(mm, dd, yyyy) show three pieces that look right
  • By the next line, are month, day and full_year integers, or still strings
  • For the year 2026, does century hold 20 and decade hold 26
  • Does the last line print exactly 11-25-2026: Wednesday, colon and one space included

Try It: Splitting a Year

Fix the two lines so they print 20 26.

  • Both operators you need take 100. One keeps what division throws away
  • Then change the year to 1999 and confirm you get 19 99

              

Session 1

Comments

Lines Python ignores, written for the humans reading your code.

  • # starts a comment. Everything after it on that line is skipped when the program runs
  • The # TODO: lines in main.py are comments. They are instructions to you, not code
  • A comment can sit on its own line, or trail one: decade = full_year % 100 # 2026 becomes 26
  • Two spaces before a trailing #. That is the spacing Python programmers expect to see

Comment the Why, Not the What

  • # add one to count above count = count + 1 says nothing the code did not already say
  • # a leap year adds an extra day explains something the code cannot say for itself
  • The triple-quoted block at the top of main.py is a docstring. Put your name on its Author: line
  • Delete each # TODO: once you have done it. A file still full of them reads as unfinished
  • A comment that is wrong is worse than no comment. Update it when you change the line under it

Try It: Comments

Run it. Fix line 3. Then comment out line 2 and add a line of your own.

  • Nothing prints at all, not even line 2. Python checks the whole file before it runs any of it
  • Line 3 is the problem: its trailing text is not marked as a comment yet
  • The error names the line number. Start there every time

              

Session 1

Markdown

The other file you edited in lab: docs/summary.md.

  • A .md file is plain text plus a few punctuation marks that mean formatting
  • GitHub renders it for you. That is why a README looks like a document on the repository page and like symbols in the editor
  • The four questions waiting in docs/summary.md are written in markdown too
  • Nothing is hidden. The characters you type are the entire format

The Whole Syntax You Need

Click Preview to see what this becomes. Then click Write and change it.

  • Add a third bullet, and make one word in it bold
  • A blank line is what separates one paragraph from the next. Take one out and preview again

Your Lab Summary Is Markdown

Replace the first TODO with a real two-sentence answer, then Preview.

  • Each question is a > blockquote, and the word TODO under it is the placeholder
  • Delete the marker itself. Answer in full sentences, not fragments
  • Preview before you push, so you catch a heading that did not render

Previewing Markdown for Real

The box on the last two slides is a demonstration. Here is where you do it.

  • In VS Code, open the .md file and press Cmd+Shift+V on a Mac, Ctrl+Shift+V on Windows
  • Or click the split-pane preview icon at the top right of the editor to get both at once
  • On GitHub, every .md file is already rendered when you view it in the browser
  • Markdown joins consecutive lines into one paragraph. A blank line is what actually breaks them apart

Week 3 · Session 2

Working With Strings

Joining them, repeating them, and converting into and out of them.

Session 2

Joining Strings With +

  • "Good" + "bye" gives "Goodbye". No space appears unless you put one there yourself
  • first + " " + last is how two names become "Ada Lovelace"
  • + between two numbers adds. + between two strings joins. Same symbol, and the types decide which job it does
  • "Room " + 101 is an error. "Room " + str(101) gives "Room 101"

Try It: Joining

Run it first. Line 3 prints but is wrong, and line 6 crashes.

  • Fix line 3 so a space lands between the two names
  • Fix line 6 by converting room with str()

              

Session 2

Repeating Strings With *

  • "ha" * 3 gives "hahaha". A string times a whole number repeats it
  • "=" * 50 gives a line of fifty equals signs, which is how a banner line gets printed
  • That is one number to change when you want a longer line. Typing fifty equals signs is not
  • "ha" * "3" is an error. The count has to be an int, not a string

Try It: Repeating

Run it, fix the last line, then change every 10 to 24 and run it again.

  • The last line fails for the same reason "Room " + 101 did, in the other direction
  • Then add a line that prints your own name three times with a space after each copy

              

Session 2

Three Ways to Print the Same Thing

All three are correct Python. They differ in how much you have to track yourself.

  • print("Total:", total): commas, and Python puts a space between each piece for you
  • print("Total: " + str(total)): joining, so every character is yours, including that space
  • print(f"Total: {total}"): an f-string, which converts for you and keeps the text readable
  • You will read all three in other people’s code. Write whichever makes the line clearest

Your Turn: One Line, Three Ways

Fill in all three so each prints: notebook costs 3 dollars

  • The comma version is the one to watch. Check exactly where the spaces land
  • Only one of the three needs str(). Work out which, and why

              

Session 2

Converting Between Types

  • int("26") gives 26. str(26) gives "26". float("3.5") gives 3.5
  • int("3.5") is an error. Go through float first: int(float("3.5")) gives 3
  • input() always hands back a string, so a number the user typed always needs converting
  • len("Lovelace") gives 8, the number of characters, and that is an int you can do arithmetic on

Before Lab

Lab 1 Is Due at 2:30 Today

  • Run uv run gatorgrade --config gatorgrade.yml from the top folder of your repository, not from inside src
  • Finish docs/summary.md. It is graded, it is markdown, and it takes one preview to check
  • git add ., then git commit -m "message", then git push. Nothing counts until it is on GitHub
  • Your code review happens in lab this afternoon. Arrive with the project open and pushed

In Lab Today

Activity 2: The Calculation Report

Code reviews first. Then this, and it uses everything from the last two weeks.

  • Two whole numbers go in, and a formatted report of every operation we have covered comes out
  • You choose how the two numbers are separated, and your prompt has to say so
  • The sum with commas, the difference with + and str(), the product with an f-string. Same text, three ways, on purpose
  • Build the report line with repetition. Nobody types 34 equals signs
← Exit
1 / 21