What Python Is, and Where It Runs

Part I · Module 1 · Chapter 1.1 · What Python Is, and Where It Runs

1. Two Things Called Python

When someone says "I use Python", they could mean either of two things, and both are correct.

Python the language is a set of rules for writing instructions. Which words mean what. Where the brackets go. What counts as a mistake. The language is just an agreement about how to write things down — it does not do anything on its own, in the same way that English grammar does not deliver a letter.

Python the program is a piece of software installed on your computer. You give it a file of instructions written in the language, and it carries them out. This program is usually called the interpreter.

So the sentence "Python reads your file" is about the program. The sentence "Python uses indentation instead of braces" is about the language. Both are ordinary usage and you will see both constantly. You only need to notice which one is meant, and after this chapter you will.

2. What Actually Happens When You Run Something

Here is the whole model, and it is genuinely this simple:

1. You write instructions into an ordinary text file. By convention its name ends in .py.
2. You ask the Python interpreter to run that file.
3. The interpreter reads the file from the top, and carries out each instruction in turn.
4. Anything you asked it to display appears in your terminal. If it hits something it cannot make sense of, it stops and prints a message explaining what went wrong.

That is it. There is no hidden build step you have to manage, no separate linking stage, no executable to produce first.

3. A Python File Is Just Text

This surprises people, so it is worth stating plainly: a .py file contains nothing special. It is plain text. You can open one in any editor, read every character of it, and change it with a keyboard.

The .py on the end is a convention, not a requirement enforced by the file itself. It tells you, your editor and your colleagues what the file contains. Your editor uses it to decide how to colour the text.

There is no compiled artefact you have to keep in step, and nothing to rebuild after an edit. You change the text, you run it again. That short loop is the reason Python is comfortable for automation work, and you will feel it from Chapter 1.7 onward.

4. What Python Code Looks Like

Here is a small piece of real Python. You are not expected to understand it yet — Chapters 1.7 and 1.8 take apart every character of the first line, and the rest arrives across Modules 2 to 11. It is here only so that you have seen the shape of the thing.

print("Simulation complete")
print("Errors:", 0)

Two things are worth noticing even now, because they are true of all Python:

• It reads a little like English. print is an ordinary word meaning roughly what you would expect.
• Each instruction sits on its own line. There is no semicolon at the end and no braces around anything.

That readability is not an accident. It is the single property that made Python spread into engineering teams, and Chapter 1.3 looks at why that mattered.

5. Python Runs One Thing at a Time

This section exists because of a specific habit worth interrupting early.

If you have written RTL, you are used to a language where everything happens at once. Every always block in a design is live simultaneously; the order you wrote them in is irrelevant to what the hardware does. That is the whole point of a hardware description language, and it is a genuinely different way of thinking.

Python is not like that. Python does one thing, finishes it, then does the next thing. If line 1 displays a message and line 2 displays another, the first message always appears first. Nothing runs in parallel, nothing is re-evaluated when something changes, and the order you write statements in is exactly the order they happen in.

If you have never written RTL, you have nothing to unlearn here — top to bottom, one at a time, is probably what you already assumed.

6. Where Python Runs

Python is available essentially everywhere an engineer works: Linux compute farms, laptops of every kind, build servers, and inside many EDA and CAD tools that embed it. The same file generally runs on all of them.

That portability is a practical benefit rather than a philosophical one. A script you write on your laptop will usually run unchanged on a compute server, which is exactly what you want for something that has to run every night without you.

You do not need to install anything to continue reading. Chapter 1.6 shows you how to check whether Python is already on the machine in front of you — on most engineering systems, it is.

7. What You Should Be Able to Say Now

Check yourself against these. If any is unclear, this chapter is the one to re-read, because everything after it assumes all five.

1. Python is both a language and a program; the program that runs your code is called the interpreter.
2. Python code lives in an ordinary text file, conventionally ending in .py.
3. The interpreter reads that file from the top and carries out the instructions in order.
4. What you asked it to display appears in your terminal; if something is wrong, an error appears instead.
5. Python does one thing at a time. Nothing happens concurrently.

8. Exercise

No code to run yet — these are reasoning questions, and they take two minutes.

Exercise 1 — say which is meant. For each sentence, decide whether it refers to Python the language or Python the program: (a) "Python doesn't use semicolons." (b) "Python stopped with an error on line 4." (c) "Python is readable." (d) "Is Python installed on the build server?"

Exercise 2 — predict the order. Given the two-line preview in §4, which message appears first in the terminal, and why? Answer in one sentence without using the word "probably".

Exercise 3 — spot the wrong model. A colleague says: "I put the two lines in the other order but it shouldn't matter, they'll both happen anyway." Which idea from §5 is that colleague still carrying?

9. Summary

• Two things share the name Python — the language you write, and the interpreter program that runs it. Blurring them causes most early confusion; separating them costs nothing.
• A .py file is plain text. Nothing to compile and manage, nothing to rebuild. Edit, run, look at the result.
• The interpreter reads top to bottom and carries out one instruction at a time, then produces output or an error.
• Nothing in Python is concurrent. Statements are actions performed once, in the order written — unlike the RTL some readers will be arriving from.
• Python runs nearly everywhere an engineer works, which is why a script written once tends to keep working elsewhere.

You now have the execution model. The next two chapters fill in the two questions readers ask immediately afterwards — what people mean when they call Python a scripting language, and why it became the default choice for this kind of work in the first place.