Make a Computer Follow Your Instructions

Your First Python Program: Code, Data, Output, and Verification

You do not need previous programming experience to begin. In this chapter, you will publish this announcement with Python:

Dynamic Humanities Field Lab
Community Storytelling Evening
Berlin | 18 October 2026 | 18:30
Welcome! Willkommen! Bienvenue! Karibu!
120

The program contains only five instructions. By the end, you will be able to run them, read them, make careful changes, deliberately break and repair one instruction, and explain what every line does. This cycle will recur throughout the series:

Run it. Read it. Change it. Break it. Fix it. Explain it.

What you will learn¶

You will learn to:

• distinguish data, code, and output;

• use print() to display text and a number;

• recognize strings, integers, function calls, and comments;

• run code in a notebook and from a .py file;

• use a basic error message to locate a mistake; and

• explain a short program without hiding behind technical vocabulary; and

• audit a supplied AI-style answer against a simple brief.

Variables, calculations, keyboard input, and collections come later. This chapter keeps the program deliberately small so that you can understand every character you execute.

Why learn Python when AI can generate code?¶

An AI assistant could generate five print() calls in seconds. That does not remove the need to learn programming. A generated answer can run while changing the requested title, inventing a date, losing an accent, using the wrong capacity, or solving a different problem.

Your goal is not to compete with AI at typing. Your goal is to understand what you asked for, recognize what code does, notice when it is wrong, test its behavior, and remain responsible for the result. We begin with a program small enough for you to understand completely.

The main work in this module is AI-free so that you establish your own baseline. Near the end, you will inspect an instructor-supplied AI-style proposal. You will not ask a tool to complete the work for you.

1. Meet the Dynamic Humanities Field Lab¶

The Dynamic Humanities Field Lab is the recurring practice context for this course. Imagine a small team working with community events, stories, publications, languages, cultural objects, and public collections. Python will help the team communicate, organize information, check work, and later analyze data.

The Field Lab connects the course, but it is not one fixed dataset. Early examples are designed for learning. Later chapters introduce prepared public data when it genuinely helps you learn files, APIs, and applied projects.

For this chapter, we use five designed cultural-program records. Here is one:

This is a teaching example, not a real event listing. That matters: a program can display information, but it does not make the information true.

You may later adapt the same five-line structure to a community event, poetry announcement, museum or heritage item, or oral-history workshop. The context can change while the learning outcome stays the same.

Data, code, and output¶

These three words play different roles:

• Data represents information, such as a title, date, greeting, or capacity.

• Code consists of instructions written for a computer to execute.

• Output is what a running program displays or produces.

If the data says the city is Berlin, the code may instruct Python to display Berlin, and the output will contain Berlin. Python did not discover or verify the city; it followed an instruction.

Pause and predict¶

Look at the record above. Which five pieces of information would you include in a short public announcement? Write your answer before continuing.

2. Your first instruction¶

Here is a complete Python instruction:

print("Dynamic Humanities Field Lab")

When Python executes it, the output is:

Dynamic Humanities Field Lab

That single line is a real first achievement. You wrote an instruction, asked Python to execute it, predicted a result, and verified what happened. Programming capability grows by repeating that cycle with increasingly meaningful problems—not by typing quickly.

The parts have jobs:

• print is the name of a built-in function that displays output;

• the parentheses () hold the value given to the function;

• the quotation marks delimit a piece of text; and

• the text inside them is a string literal—a text value written directly in code.

The quotation marks guide Python. They do not appear in the displayed output.

Try it¶

Run the instruction. Then change Field Lab to Learning Lab and run it again. You have modified a program even though its overall structure stayed the same.

3. Build the announcement one line at a time¶

Python normally executes these instructions from top to bottom:

# Publish the selected cultural-program record.
print("Dynamic Humanities Field Lab")
print("Community Storytelling Evening")
print("Berlin | 18 October 2026 | 18:30")
print("Welcome! Willkommen! Bienvenue! Karibu!")
print(120)

Before running it, predict the exact output. How many lines will appear? Will the quotation marks appear? Where will the number appear?

The first line begins with #. It is a comment for people reading the code. Python does not display it. Comments can record intent, but they should not repeat what is already obvious.

The last call contains 120 without quotation marks. It is an integer literal, a whole-number value written directly in code. Both of the following display similar-looking output, but they represent different kinds of values:

print("120")  # text
print(120)    # a whole number

The distinction becomes important when you calculate in the next chapter.

A useful imperfection¶

The final output line is only 120. A reader cannot know whether it represents seats, minutes, records, or euros. The code runs correctly, but the communication is weak. In Chapter 2, variables and formatted output will help us produce a clearer label such as Planned capacity: 120.

Correct execution is necessary; clear communication also matters.

4. Modify without losing control¶

Use the record CP003 from the designed sample:

Modify the announcement so that it displays this workshop. Keep the first heading, use at least two greetings, and keep five output lines.

A careful workflow is:

1. predict which lines must change;

2. change one line at a time;

3. run the program;

4. compare the output with the record; and

5. explain what you changed and why.

This is more reliable than changing everything and hoping it works.

5. Notebook, interpreter, and source file¶

You can work with the same Python language in several environments.

Notebook¶

A notebook contains cells. You can combine explanations, code, and visible results. It is useful for guided learning and exploration. Cells can be run out of order, however, so later notebooks will include a restart-and-run check.

Source file¶

A Python source file ends in .py. The reference program for this chapter is named cultural_program.py. From a terminal in its directory, run:

python cultural_program.py

On systems where the command is named python3, use:

python3 cultural_program.py

Saving the file does not execute it. The run command asks a Python interpreter to execute its instructions.

Interpreter¶

The interpreter is the program that reads and executes Python instructions. A notebook sends code to a Python interpreter; the terminal command also starts a Python interpreter for the source file.

The simple flow is:

your Python code -> Python interpreter -> output or an error message

You do not need to choose one environment forever. Use the guided notebook to learn, and use the source file to practice running a complete program.

6. Your first error is useful information¶

Consider this broken instruction:

print("Community Storytelling Evening)

One closing quotation mark is missing. Python cannot determine where the text ends, so it reports a SyntaxError. A syntax error means the written instruction does not follow Python’s grammatical rules.

Use this beginner debugging routine:

1. Pause. An error is evidence, not a verdict about your ability.

2. Read. Start with the final line of the message.

3. Locate. Inspect the indicated line and nearby characters.

4. Compare. Compare it with a working example.

5. Change one thing. Replace the missing quote.

6. Rerun. Confirm that the output now matches your prediction.

Here is another broken instruction:

print("Berlin | 18 October 2026 | 18:30"

This time the closing parenthesis is missing. Repair it without changing the text.

You are not yet learning how programs catch runtime exceptions; that belongs later. For now, the goal is to read rather than fear a simple message.

7. Explain the completed program¶

Being able to reproduce code is not enough. Explain the reference program in plain language:

1. The comment tells a human reader why the following instructions exist.

2. The first print() call displays the organization heading.

3. The next calls display the event title, place and time, and multilingual welcome.

4. The last call displays an integer representing planned capacity.

5. Python executes the calls from top to bottom and produces five output lines.

Then state one limitation: the capacity lacks a label, and all values are fixed directly in the code. Chapter 2 addresses both limitations.

8. AI can propose; you must verify¶

Suppose the brief says:

Publish CP003 with five output lines: Field Lab heading; Oral Histories Workshop; Nairobi, 21 November 2026 at 10:00; a greeting containing Karibu; integer capacity 40.

An AI-style proposal might look convincing:

print("Dynamic Humanities Field Lab")
print("Oral History Festival")
print("Nairobi | 22 November 2026 | 10:00")
print("Welcome!")
print(400)

The program is valid Python and will run. It is still wrong for the brief: it changes the title and date, omits the required greeting, and multiplies the capacity by ten.

Audit it without using an AI tool:

1. turn the brief into five checkable requirements;

2. predict the proposal’s output;

3. compare every output line with the brief;

4. correct only the mismatched values;

5. run the corrected program; and

6. explain why “it runs” is not the same as “it is correct.”

This is the course’s position in miniature: AI may propose; the human remains responsible for specifying, inspecting, testing, interpreting, and deciding.

Practice ladder¶

Observe¶

Circle the function name, parentheses, quotation marks, string value, integer value, and comment in the reference program.

Try¶

Change one greeting and run the program. Record the line that changed.

Practice¶

Reorder the title and location calls. Predict the output, run the code, and explain why the order changed.

Apply¶

Create a five-line announcement for CP003 or CP005 from the supplied sample. Alternatively, use the same structure for a designed book, museum, or oral-history announcement supplied by your instructor.

Challenge¶

The following program has two syntax mistakes. Repair it:

print("Dynamic Humanities Field Lab")
print("Poetry Across Languages)
print("Brussels | 6 November 2026 | 19:00"
print("Bienvenue!)
print(80)

Explain¶

In four sentences, distinguish data, code, output, and an error message using your own program. Add one sentence explaining why generated code must be verified even when it runs.

Concept reference¶

Checkpoint¶

Without copying the reference:

1. create a five-line cultural announcement;

2. include at least one multilingual line and one integer;

3. include one useful comment;

4. run it in a notebook or as a source file;

5. compare the output with your prediction; and

6. explain every line.

Label this task AI-free. Course materials, Python execution, error messages, and supplied hints are allowed. Generated code, answers, prose, or debugging changes are not allowed. Submit your prediction, actual output, debugging note, and explanation as evidence of your own baseline. Later modules will explicitly identify when AI support is appropriate.

Summary and next step¶

You used code to display selected cultural information, distinguished code from data and output, ran the same language in two working environments, repaired simple syntax mistakes, and identified errors in a plausible proposal. More importantly, you practiced the course’s recurring method: Run it. Read it. Change it. Break it. Fix it. Explain it.

The current program contains fixed values and an unlabeled number. In the next chapter, you will use variables, calculations, input, and formatted output to build a useful Cultural Event Attendance and Cost Calculator.

Example note¶

The records in this chapter are instructor-designed teaching examples, version 1.0. They are not derived from an external dataset and must not be treated as claims about real events or organizations. No external source or license is required for the example data.