Variables and data types

Understand the concept

Assignment connects a name to an object

Yesterday, changing the daily target required editing more than one literal. A variable gives that value a name. In daily_minutes = 90, Python evaluates the expression on the right and binds the name on the left to the resulting object. Assignment is an action; it is not a claim that both sides were already equal.

Read total = days * daily_minutes as “calculate the product now, then bind total to the result.” It does not create a spreadsheet formula that automatically recalculates whenever either input changes. If you later reassign daily_minutes, the existing total remains its earlier value until you execute the calculation again. This distinction explains many stale-report bugs.

Use names that describe the field: daily_minutes communicates more than x. Python names are case-sensitive, so Days and days are different names. A name cannot begin with a digit, contain a space, or use a reserved keyword such as for. Prefer lowercase words separated by underscores. Avoid replacing useful built-in names such as str, list, or sum with your own values.

A value's type determines its useful operations

An integer represents a whole number; a float represents a floating-point number; a string represents text; and a Boolean represents true or false. None represents the absence of a value under a contract you define. It is not the same as the integer zero, an empty string, or False.

Choose the type from the field's meaning. A count of completed lessons is an integer. A display name is a string. A completion flag can be a Boolean. A score not yet recorded can be None. An identifier such as "0017" should stay text when its leading zeros matter. A sequence of digits does not automatically represent a quantity.

Python has dynamic typing: a name can later be rebound to a different kind of object. That flexibility does not make accidental type changes desirable. If completed_days changes from 3 to "three", calculations that expect a number stop making sense. Track the meaning of the name as well as its current type.

Conversion is a decision with limits

int("30") converts suitable numeric text to an integer, and str(30) produces textual digits. A conversion is not a general data-quality repair. int(3.9) truncates toward zero rather than rounding to the nearest integer. int("3.9") raises ValueError because that string is not an integer literal accepted by the conversion.

For ordinary truth-value conversion, a nonempty string is true. Consequently, bool("False") is True. It asks whether the string is nonempty, not whether its English spelling means false. If a configuration file uses the strings “true” and “false,” you need an explicit parsing rule.

Worked example

learner = "Alex"
days = 30
daily_minutes = 90
completed_days = 3
is_started = True
last_score = None

total_minutes = days * daily_minutes
print(learner, total_minutes)
print(type(days).__name__, type(learner).__name__)

daily_minutes = 60
print("Stored total:", total_minutes)
total_minutes = days * daily_minutes
print("Recalculated total:", total_minutes)
print("Score missing:", last_score is None)

type(value).__name__ displays a type's name for inspection. You do not need to understand classes yet to use it as a learning aid. The final missing-value test uses is None, a convention explained more fully on Day 4.

This trace is more informative than simply saying “variables can change.” It records which bindings change at each statement. When debugging, make this kind of small state table for the specific names involved.

Guided practice

1. Predict: determine the values and types of 7, 7.0, "7", False, and None. Explain why 7 == 7.0 can be true while the two objects still have different types.
2. Modify: add completed_minutes = completed_days * daily_minutes to the program. With three completed days and a 60-minute target, expect 180. Describe that value as a planned calculation, not actual tracked time: real sessions might last different lengths.
3. Reconstruct: define a text learner ID with leading zeros, a display name, a completed-day count, and an optional score. Print each type. Explain which field would lose information if converted to an integer.

Do not write “all numeric-looking values must become numbers” in your notes. Write a field-level policy instead: counts are integers; identifiers preserve their original text; missing observations remain separate from known zeros.

Daily challenge

Refactor the study card so each input appears in one assignment. Add a remaining-days calculation. Use fictional inputs learner = "Alex", days = 30, daily_minutes = 90, and completed_days = 3. The program should print the learner, planned total minutes, and remaining days. Changing only daily_minutes must update the planned total after rerunning the whole script.

For today, assume completed_days is between zero and days. This is an explicit input assumption, not validation. Day 5 will add a decision for invalid counts. Keep the assumption in a comment so a later reader knows what the calculation relies on.

Reference solution

learner = "Alex"
days = 30
daily_minutes = 90
completed_days = 3  # Assumed to be between 0 and days.

planned_minutes = days * daily_minutes
remaining_days = days - completed_days
print("Learner:", learner)
print("Planned minutes:", planned_minutes)
print("Remaining days:", remaining_days)

Debug and explain

Explain why bool("False") is true, why "0017" should remain text, and why changing daily_minutes does not rewrite an earlier result. Give an example where zero is a valid observation. Tomorrow you will receive values from a user rather than from literal assignments, making these distinctions essential.

Review and next step

Keep a state trace and the three challenge outputs. On your next review, rebuild the assignments without copying. You are ready for Day 3 when you can choose meaningful types and identify where conversion belongs.