Python Basics in 8 Slides

This post pulls back the curtain on what actually happens when you run Python. You don't need to know the internals to write working code, but knowing them transforms your relationship with the language. Surprising behavior stops being surprising once you can picture the machine underneath.

We'll trace the path from source text to running program, look at how values are stored and shared, and explain why indentation and functions behave the way they do. This is the mechanical foundation under the vocabulary from post one.

The execution pipeline is more involved than 'Python just runs the file,' though that's a fine first approximation. Under the hood, the interpreter first parses your source into an abstract syntax tree, then compiles that tree into bytecode — a compact, platform-independent instruction set. That bytecode is what actually executes, on the Python Virtual Machine.

This is why you sometimes see .pyc files appear: Python caches the compiled bytecode so it doesn't have to recompile unchanged modules. So Python is both 'interpreted' (you run source directly) and 'compiled' (to bytecode) — the labels aren't contradictory once you see the full pipeline.

The pipeline diagram lays out the four stages in order: source text, parse to a tree, compile to bytecode, execute on the virtual machine. Each stage has a clear job, and errors surface at predictable points — syntax errors during parsing, runtime errors during execution.

Knowing where in the pipeline an error occurs helps you diagnose it. A SyntaxError means the parser couldn't even build the tree; your code never ran at all. A NameError or TypeError means parsing and compilation succeeded but something went wrong while the VM was executing. That distinction alone speeds up debugging.

References are the heart of Python's value model, and getting them right prevents a huge class of bugs. Every value is an object on the heap with three things: an identity (its address, seen via id()), a type, and the value itself. A variable is merely a name bound to one of these objects.

The consequence that surprises everyone: `b = a` does not copy the object, it creates a second name pointing at the same object. For immutable values this never matters because you can't change them in place. For mutable values like lists it matters enormously, because a change through one name is visible through the other.

The diagram shows two names, a and b, both pointing at a single list object. There's exactly one list in memory; the names are just two arrows to it. Append through b and a sees the change, because there was only ever one list.

This single picture explains the most common 'why did my other variable change?' bug. Keep redrawing it whenever shared-state confusion strikes. The fix, when you want independence, is to explicitly create a new object with .copy() or list() — which we cover head-on in post five.

Indentation-as-syntax is a defining Python choice and this code shows it in action. The body of each if, elif, and else branch is defined purely by being indented under it. There are no braces and no 'end' keywords — the whitespace carries the structure.

The classify function and the loop together demonstrate control flow and iteration in one tight example. Run it and you'll see each score routed to the right branch. Then deliberately mis-indent a line and watch Python complain — that error is the language enforcing the structure that, in other languages, is merely convention.

This code slide is worth running line by line because it packs control flow, iteration, and function definition into one small example. The classify function uses an if/elif/else ladder whose branches are defined purely by indentation, and the loop below drives it over three scores, printing the routed result for each.

Notice how the indentation visually mirrors the logic: the function body is indented under def, and each branch body is indented under its condition. The structure you see is the structure Python executes — there's no separate set of braces that could disagree with the layout. That tight coupling of appearance and behavior is exactly what makes Python so readable.

Functions in Python are objects, just like everything else. The def statement does two things: it builds a function object containing the compiled body, and it binds a name to that object. Calling the function creates a fresh local scope, binds the arguments to the parameter names, runs the body, and returns a value.

Two details catch beginners. First, arguments are passed by assigning them to parameters — same reference semantics as any assignment, so passing a mutable object lets the function modify it. Second, a function with no explicit return still returns something: None. Forgetting this leads to the classic 'why is my result None?' confusion.

Mutability is the property that ties this whole post together. Immutable types — int, float, str, tuple — cannot be changed in place; any 'modification' actually creates a new object. Mutable types — list, dict, set — can be changed in place, which is powerful but means shared references can surprise you.

The practical guidance: immutable objects are safe to share freely because no one can alter them under you. Mutable objects require care — know who else holds a reference before you change one. This single property explains why tuples are safe dict keys and lists aren't, and why mutable default arguments are a trap.

These five points are the execution model in miniature: parse then compile then run bytecode; values are heap objects; names are bindings rather than boxes; indentation defines every block; and functions return None unless told otherwise. Memorize these and Python stops feeling magical.

Each point connects to a real debugging scenario. Misread any one of them and you'll hit a specific, predictable class of bug. Internalize all five and the language becomes something you can reason about rather than something you poke at hopefully.

Mixing tabs and spaces is the canonical Python beginner injury, and it follows directly from indentation being syntax. Because the interpreter measures indentation precisely, a line that looks aligned but uses a tab where its neighbors use spaces is, to Python, at a different level — producing either an IndentationError or silently wrong block structure.

The fix is simple and permanent: choose spaces (PEP 8 standardizes on four), configure your editor to insert spaces when you press Tab, and turn on 'show whitespace' if you're ever unsure. Set this up once and you'll never lose an afternoon to invisible whitespace again.

That closes the how. You've now seen the machine: source becomes bytecode becomes execution, values are shared objects on the heap, indentation is real syntax, and functions are objects that run in their own scope. This mechanical picture is what makes Python's behavior predictable.

Next we leave the theory entirely and write code you can run today — variables, the four core data structures, loops, conditionals, functions, and comprehensions. Bring a REPL.