Input, Output and Comments

You have used print() since the first lesson; now meet its useful details. print() can take several values at once, separated by commas, and it puts a single space between them and moves to a new line at the end:

room = "Kitchen"
area = 12.5
print("Room:", room, "Area:", area)
# Room: Kitchen Area: 12.5

Two optional settings control that behaviour. sep sets what goes between the values (default a space), and end sets what goes at the end (default a newline):

print("A-101", "A-102", "A-103", sep=" | ")
# A-101 | A-102 | A-103
print("Loading", end="...")
print("done")
# Loading...done   (both on one line, because end was not a newline)

For anything with numbers in it, though, the f-string from the last lesson usually beats juggling commas - it gives you full control of spacing, wording and number formatting in one readable piece:

print(f"Room: {room:<10} Area: {area:>6.1f} sqm")
# Room: Kitchen    Area:   12.5 sqm

Here :<10 left-aligns the room name in a 10-character space and :>6.1f right-aligns the number in 6 characters with one decimal - the trick for printing tidy, column-aligned tables straight to the screen. You do not need every format code memorised; know that print() plus f-strings can make output as clean as you want, and reach for alignment codes when you are lining up a little report.

There is a second, quieter use of print() that will save you constantly: checking what your code is actually doing. When a script misbehaves, dropping a print() in the middle to show a value - print("area so far:", area) - reveals whether the numbers are what you assumed at that point. This throwaway 'print debugging' is the simplest tool for finding where reality diverged from your expectation, and even seasoned programmers reach for it before anything fancier. So print() wears two hats: the polished output a user reads, and the rough running commentary you sprinkle in while building and then delete once it works.

To ask a person for a value, use the `input()` function. You give it a prompt to show, and it waits for the person to type something and press enter, then hands you back what they typed:

name = input("Room name: ")
print("You entered:", name)

Run that and the script pauses, shows Room name: , and whatever you type becomes the value of name. Simple - but there is one rule you must never forget, and it is the single most common input() bug: `input()` always gives you a string. Even if the person types 12, you receive the text "12", not the number 12. So before you can calculate with it, you convert:

length_text = input("Wall length in m: ")  # a string like "6"
length = float(length_text)                # now a number: 6.0
# or, more compactly, wrap it in one line:
height = float(input("Wall height in m: "))
area = length * height
print(f"Wall area: {area:.2f} sqm")

That float(input(...)) pattern - ask, then immediately convert - is one you will write hundreds of times. Use int() when you want a whole number (a count of sockets), float() when a decimal makes sense (a length or rate). This is exactly the text-to-number conversion from the previous lesson, now with a clear reason to care: the outside world hands your program text, and you translate it at the door.

A few practical notes. You can ask for several values in a row, one input() per line, and the script simply pauses at each until the person answers - that is how the interactive tool at the end of this lesson gathers a whole set of dimensions. Write prompts that are clear and include the unit you expect: "Wall length in m: " tells the person both what to type and in what unit, heading off the classic mismatch where you assumed metres and they typed centimetres. And be aware that input() will accept anything, including nonsense - if someone types "wide" when you asked for a length, the float() will raise a ValueError and stop the script. For your own tools that is usually fine; gracefully surviving bad input is a Module 3 topic (try/except). For now, clear prompts and immediate conversion cover the vast majority of real use.

A comment is a note in your code for humans, which Python ignores entirely when running. Anything after a # on a line is a comment:

# tile budget for the lobby floor
area = 24.5
rate = 1450        # unit rate per square metre
cost = area * rate * 1.08   # 8 percent added for cutting waste
print(cost)

Python runs area = 24.5 and skips everything green after the #. Comments cost nothing and are worth an enormous amount, for one reason: code tells you _what_ it does; comments tell you _why_. The line cost = area * rate * 1.08 is clear enough about the multiplication, but only the comment explains that the 1.08 is a waste allowance - the piece of intent that is invisible in the maths and impossible to reconstruct later. Six weeks from now, that note is the difference between understanding your own script and staring at it.

The craft of commenting is knowing what not to write. A comment that just restates the code - area = 24.5 # set area to 24.5 - is noise; it adds nothing and rots as the code changes. Good comments capture the things code cannot say: why a number is what it is, where a magic figure came from, an assumption you made, or a warning about a tricky bit. Aim to explain reasoning, not mechanics. A short, honest comment above a chunk of code - # assumes rectangular rooms; splits L-shapes elsewhere - is one of the kindest things you can leave for the next person, who is very often you.

Comments have a second, humbler use while you work: switching code off without deleting it. Put a # in front of a line and Python skips it, so you can silence a print() you were using to check a value, or park a line you are unsure about, then restore it later by removing the #. Most editors do this to a whole selection with a keyboard shortcut (often Ctrl-/ or Cmd-/). This 'commenting out' is a everyday move when hunting a bug - disable half the script, see if the problem goes away, and narrow down where it lives - and it beats deleting code you might want back in a minute.

Working code and good code are not the same thing, and the gap is almost entirely readability - because you will read a script far more often than you write it. A handful of cheap habits, applied from now, make everything downstream easier.

Name things meaningfully (from Lesson 1.2): wall_area, not w. Use blank lines to separate a script into logical paragraphs - inputs together, then the calculation, then the output - so the shape is visible at a glance. Comment the why, not the what. And keep each line doing one clear thing rather than cramming a page of logic into a dense one-liner. Compare:

print(float(input("L: "))*float(input("W: ")))   # works, but opaque

with:

# floor area from length and width the user enters
length = float(input("Length in m: "))
width  = float(input("Width in m: "))
area   = length * width
print(f"Floor area: {area:.2f} sqm")

Both compute the same number. The second you can read, check, reuse and hand to someone else; the first you will not understand next week. This is not perfectionism - your scripts can stay small and rough (that is the point of scripting) - it is the small discipline that keeps rough scripts usable. As the code you write grows past a few lines, readability is what stops it collapsing into a tangle, and it is the habit AI assistants and teammates both depend on to help you.

Everything in Module 1 now combines into a small tool that asks, computes and reports - the shape of countless useful scripts. Here is an interactive paint estimator that a colleague with no coding knowledge could run:

# Simple paint estimator - asks for a wall, reports litres and cost
print("--- Paint Estimator ---")

# inputs (convert text from input() into numbers straight away)
length = float(input("Wall length in m: "))
height = float(input("Wall height in m: "))
rate   = float(input("Paint price per litre: "))

# assumptions
coverage = 10   # sqm covered by one litre, one coat
coats    = 2    # standard two coats

# process
area   = length * height
litres = area * coats / coverage
cost   = litres * rate

# output
print(f"Wall area : {area:.1f} sqm")
print(f"Paint     : {litres:.1f} litres ({coats} coats)")
print(f"Est. cost : {cost:,.0f}")

Run it and it holds a small conversation, then prints a clean three-line report. Read its structure, because it is the template for almost everything ahead: a header, inputs converted at the door, named assumptions with comments explaining them, a process block of calculation, and a formatted output block. It is interactive, readable, and genuinely useful - a real tool you built from nothing but the pieces of this one module. That arc, from print("hello") in Lesson 1.1 to a working estimator here, is the whole promise of the course in miniature: small, clear instructions, combined, become leverage.

It is worth pausing on how far you have come in one module. You can install and run Python; store values in named variables of the right type; compute with arithmetic, build text with f-strings, compare values and convert between text and numbers; and now take input, present clean output, and document your reasoning. Put together, those are enough to write a genuinely useful single-run tool - and thousands of real design scripts are exactly that: ask, compute, report. What this estimator still lacks is the ability to decide (charge differently for a wet area) and to repeat (run over every room in a project, not one at a time). Those two powers - decisions and loops - are the whole of Module 2, and they are where a script stops being a fancy calculator and starts being the labour-saving engine the first lesson promised.