Input Makes Programs Interactive

Core path: 30 minutes

What changes when the data comes from the user instead of the source file?

Until now, the developer has chosen most values ahead of time:

name = "Nova"
age = 15

That means the source code already contains the data.

input() changes the relationship. The program pauses, waits for somebody to provide information, and then continues with a value that did not exist when you wrote the file.

One complete input transaction

Run:

name = input("What is your name? ")
print(f"Hello, {name}.")

Read what actually happens:

program reaches input()
        ↓
prompt is displayed
        ↓
user types characters
        ↓
user presses Enter
        ↓
input() returns text
        ↓
name refers to that string
        ↓
print() uses the value

That is the first interactive data path in the course.

The important part is not the arrow art. Each step represents a change in the program's state or control.

input() returns a string

This surprises almost everybody once:

age = input("How old are you? ")
print(age)
print(type(age))

Type:

15

Python reports:

<class 'str'>

The keyboard gave the program characters. input() returns those characters as a string.

Python does not inspect 15 and decide that you probably wanted an integer.

Remember Week 1: the machine receives what is actually represented, not your intention.

The broken calculator is doing exactly what you asked

first_number = input("First number: ")
second_number = input("Second number: ")

total = first_number + second_number
print(total)

Enter:

10
5

Output:

105

Why?

Trace the types before blaming the operator:

first_number  → "10" → str
second_number → "5"  → str

"10" + "5"
      ↓
string concatenation
      ↓
"105"

Python is not bad at arithmetic. The program never gave it two numeric values to add.

Run the complete path and inspect both the raw string behavior and the converted numeric behavior:

Run the code to see output.

Conversion changes the representation

Repair the calculator:

first_number = int(input("First number: "))
second_number = int(input("Second number: "))

total = first_number + second_number
print(total)

Now the path is:

user types "10"
        ↓ input()
string "10"
        ↓ int(...)
integer 10
        ↓
10 + 5
        ↓
15

The conversion is not just syntax you wrap around input(). It changes what kind of value the rest of the program receives.

Conversion can fail too

What happens here?

age = int(input("Age: "))

if the user types:

fifteen

int() cannot create an integer from that text, so Python raises a ValueError.

This is important:

input succeeded
conversion failed

Those are different stages.

Later we will handle invalid input more deliberately. Right now, learn to identify which operation failed.

Use float() when decimal values are valid

This fails:

price = int("19.95")

because 19.95 is not an integer representation.

Use:

price = float(input("Price: "))

Now values such as 19.95 can be represented as floating-point numbers.

Do not choose float() simply because it seems more powerful. Choose a type that matches the data and the operations the program needs.

Build a temperature converter

fahrenheit = float(input("Temperature in Fahrenheit: "))
celsius = (fahrenheit - 32) * 5 / 9

print(f"{fahrenheit}°F is {celsius:.1f}°C")

For 32, predict the result before running.

Then try 212.

The expression:

(fahrenheit - 32) * 5 / 9

is the processing stage. The f-string is presentation.

Keep those jobs conceptually separate even when they appear only one line apart.

Similar-looking output can hide different data

Predict:

x = "5"
y = 2
print(x * y)

Output:

55

Python defines string × integer as repetition.

Again, valid execution does not guarantee the behavior matched your intention.

This is why the Week 3 habit is:

print(value)
print(type(value))

when the result feels wrong.

Trace one user value end to end

Use:

hours_text = input("Hours this week: ")
hours = float(hours_text)
daily_average = hours / 7
print(f"Daily average: {daily_average:.1f}")

If the user types 14, document:

keyboard input:
value returned by input():
type returned by input():
value after float():
type after float():
calculation:
final output:

That trace is more useful than memorizing "input returns strings" as a disconnected fact.

Before Lesson 4

You should be able to look at a user-input line and answer:

• What type does input() return?
• Is conversion needed?
• What type should the conversion produce?
• Which later operation requires that type?
• What failure would appear if the user enters an incompatible value?

Lesson 4 turns those decisions into a larger profile program. Lesson 5 follows one value through the whole chain.