Input/Output & f-string Formatting

input() — Always a String, No Exceptions

input() pauses your program, waits for the user to type something and press Enter, and returns whatever they typed. You have used it in passing since the Variables module, but it is worth being precise about exactly what it does and does not do, since the single most common mistake with input() stems from a wrong assumption about its return type.

age = input("Enter your age: ")
# User types: 25

print(type(age))    # <class 'str'>
print(age)              # "25"     — the STRING "25", not the integer 25
print(age + 1)             # TypeError: can only concatenate str (not "int") to str

This is not a special case or a quirk — it is the entire, consistent contract of input(): whatever the user types, no matter how number-like it looks, comes back as a string. If your program needs a number, you must convert it explicitly, exactly as covered in the Variables & Data Types module.

age = int(input("Enter your age: "))       # convert immediately, at the point of input
price = float(input("Enter the price: "))

print(age + 1)      # 26 — now this works, because age is actually an int

The prompt argument — and why it matters more than it looks

The string passed to input() is displayed to the user before the program waits for their response — this is not just a convenience, it is the only signal the user gets that the program is waiting on them at all. input() with no prompt argument still works and still waits, but silently, which reads to a user as a frozen or crashed program.

# Confusing — the program appears to hang with no explanation
name = input()

# Clear — the user immediately understands what's expected
name = input("Enter your name: ")

split() and Unpacking — Reading Several Values in a Single input()

Prompting separately for every individual value is tedious for both the programmer and the user. A very common real pattern — especially in command-line tools and coding exercises — is reading several space-separated values from a single line of input, then splitting and unpacking them in one step.

# User types: Maria 28
name, age = input("Enter your name and age: ").split()

print(name)     # Maria     — a string
print(age)         # "28"      — still a string! split() does not know these should be numbers

.split() with no arguments splits on any amount of whitespace and discards it — the same string method you already met in depth in the Strings module. The result is a list of strings, which is then unpacked directly into name and age using the same tuple/list unpacking mechanics from the Tuples and Sets module. As always, the number of names on the left must match the number of items produced by .split(), or Python raises a ValueError.

# User types: 4 7
a, b = input("Enter two numbers: ").split()
a, b = int(a), int(b)          # convert both after splitting
print(a + b)                     # actually adds them numerically now

# Or, more compactly, with map() — a preview of the functional tools
# module (26) you'll meet properly later in this track:
a, b = map(int, input("Enter two numbers: ").split())
print(a + b)

f-strings Were Already Covered In Depth — Here Is the One-Paragraph Recap

The Strings module covered f-strings thoroughly — embedding expressions directly inside a string with f"...{expression}...", format specs for decimal places, padding, thousands separators, and percentages, and the debugging shorthand f"{value=}". This module deliberately does not repeat any of that ground — if any of it sounds unfamiliar, it is worth a quick trip back to Parts 05 and 06 of the Strings module before continuing. What this module adds instead is everything around formatting — actually getting values in via input(), and actually getting formatted output onto the screen (or somewhere else entirely) correctly via print(), which is the real subject of the rest of this module.

name = "Maria"
price = 19.999

print(f"Hello, {name}! Total: ${price:.2f}")
# Hello, Maria! Total: $20.00

print() in Real Depth — sep and end

Most tutorials only ever show print() called with a single string, which hides two genuinely useful keyword arguments almost every working Python engineer relies on regularly: sep and end.

sep — what goes between multiple arguments

print() can take any number of arguments, and by default joins them with a single space. sep overrides that joining character entirely.

print("2026", "08", "15")                # 2026 08 15         — default sep is a single space
print("2026", "08", "15", sep="-")           # 2026-08-15          — a real date format, built directly
print("a", "b", "c", sep="")                    # abc                    — no separator at all
print("a", "b", "c", sep="\n")                     # a
                                                       # b
                                                       # c
                                                       # sep can be ANY string, including a newline

end — what goes after the entire print call

By default, print() appends a newline character after everything it prints — this is why consecutive print() calls appear on separate lines. end overrides that trailing character, which is exactly how the Loops module's nested-loop grid example printed multiple values on a single row.

print("Loading", end="")
print(".", end="")
print(".", end="")
print(".", end="\n")
# Loading...
# (all four calls landed on ONE line, because none of the first three
#  appended the default newline — only the last one did, explicitly)

for i in range(5):
    print(i, end=" ")
# 0 1 2 3 4    — printed on a single line, space-separated, no trailing newline mid-loop

Printing to stderr Instead of stdout — And Why the Distinction Matters

Every running program has two separate output streams available to it by default: stdout (standard output) for normal program output, and stderr (standard error) for error messages and diagnostics. By default, print() writes to stdout. The file keyword argument lets you redirect a specific print() call to stderr instead.

import sys

print("Processing started")                          # goes to stdout — normal output
print("Warning: config file not found", file=sys.stderr)   # goes to stderr — diagnostic output

On the surface, both lines appear identically in a typical terminal — the distinction only becomes visible, and useful, once output is redirected, which is extremely common in real production usage. A command-line tool's normal output might be redirected into a file for later processing, while its errors still need to reach the terminal (or a separate logging system) immediately, regardless of where the normal output is going.

# Running a script and redirecting only its normal output to a file:
# python my_script.py > output.txt
#
# If the script printed everything with plain print() (stdout),
# error messages would ALSO be silently redirected into output.txt,
# where nobody watching the terminal would ever see them.
#
# If errors were printed with print(..., file=sys.stderr) instead,
# they still appear in the terminal immediately, even though
# normal output is being captured into the file.

flush — When Output Needs to Appear Immediately, Not Whenever Python Gets Around to It

Output is not always written to the screen (or a file) the instant print() is called. For performance reasons, Python (and the underlying operating system) often buffers output — collecting it up and writing it out in a batch, rather than one line at a time — since writing to a terminal or file repeatedly, in small pieces, is slower than writing larger chunks at once.

import time

for i in range(5):
    print(f"Step {i}")
    time.sleep(1)

# In some environments (piped output, certain terminals, some logging setups),
# all five lines can appear at once after the full 5 seconds — not one per second
# as you'd expect — because the output was buffered rather than written immediately.

flush=True forces print() to write its output immediately, bypassing the buffer, rather than waiting for the buffer to fill up or the program to exit.

import time

for i in range(5):
    print(f"Step {i}", flush=True)
    time.sleep(1)

# Now each line is guaranteed to appear the moment it's printed,
# not held back in a buffer.

print() Debugging — Genuinely Useful, and Genuinely Limited

Sprinkling print() calls through code to see what a variable actually contains at a given point is, honestly, how most engineers debug small problems — including experienced ones. It is fast, requires no setup, and works everywhere Python runs. It is worth using well, and worth being honest about where it stops being enough.

def calculate_total(items):
    print(f"DEBUG: items = {items}")     # label your debug prints — you WILL have several at once
    subtotal = sum(item["price"] for item in items)
    print(f"DEBUG: subtotal = {subtotal}")
    tax = subtotal * 0.08
    total = subtotal + tax
    print(f"DEBUG: total = {total}")
    return total

Where print() debugging genuinely runs out of road

It has real, structural limits. It requires editing the source code and re-running the program for every new question you want answered. It clutters real code if forgotten and left in (worse, if it accidentally ships to production). It cannot pause execution and let you inspect the full program state interactively, and it becomes genuinely unmanageable in a large codebase or a bug that only reproduces intermittently, where adding and removing print statements repeatedly across many files is slow and error-prone.

This is exactly the gap that a real debugger fills — a tool that lets you pause a running program at an exact line, inspect every variable in scope at that moment, and step through execution one line at a time, without editing the source code at all. Python's built-in debugger and how to use it properly — including in a real IDE — is covered fully in the dedicated Debugging module later in this track. For now, print() is a completely legitimate first tool, not a beginner's crutch to feel embarrassed about — just one with a ceiling worth knowing about in advance.

A Raleigh Logistics Company's Monitoring Dashboard Goes Silent During an Actual Outage

print(f"Scanned package {package_id}: OK")
print(f"ERROR: package {package_id} failed barcode validation")   # still just stdout!

import sys

print(f"Scanned package {package_id}: OK")
print(f"ERROR: package {package_id} failed barcode validation", file=sys.stderr, flush=True)

Four Misconceptions About Input and Output

5 Interview Questions — With Complete Answers

Input/Output Mistakes Beginners Make Constantly

Errors You Will Hit With Input and Output — And Exactly Why