Python Basics in 8 Slides

This opening post sets the foundation for everything that follows in the AI series. Before you can train a model or call an API, you need fluency in the language those tools are written in. Python is that language, and this post defines the core vocabulary you'll lean on every day.

The goal here isn't to make you an expert in one post. It's to install the right mental models — what a variable really is, what a type means, how the interpreter reads your code — so that everything you learn afterward has somewhere to attach.

Python's defining traits are worth internalizing early. 'High-level' means you don't manage memory addresses or CPU registers; you think in terms of names and values. 'Interpreted' means there's no separate build step you orchestrate — you hand a .py file to the interpreter and it runs immediately, which makes the feedback loop incredibly fast for experimentation.

These two properties are exactly why Python dominates data science and AI. When you're iterating on an idea fifty times an hour, the language that lets you change a line and rerun instantly wins. Python trades a little raw speed for an enormous gain in developer speed, and for ML workflows that's almost always the right trade.

Python's rise in AI is less about the language being theoretically superior and more about gravity. NumPy made fast numerical computing accessible, pandas made data wrangling pleasant, and then scikit-learn, TensorFlow, and PyTorch all chose Python as their interface. Each library made the next one more likely to pick Python too.

The practical upshot for you: by learning Python you get the entire modern ML toolkit for free. You're not just learning a language, you're learning the lingua franca that lets you read tutorials, paste examples, and stand on the shoulders of an enormous community.

The 'variable as a label' model is the single most clarifying idea for a Python beginner. In some languages a variable is a box that holds a value, and assignment copies the value into the box. Python doesn't work that way. A variable is a name, and assignment binds that name to an object that lives elsewhere in memory.

This distinction feels academic until it isn't. The moment you do `b = a` with a list and then watch both 'change' together, the box model fails you and the label model explains everything. Getting this right now prevents a whole class of bugs later, which is why we plant it in the very first post.

The diagram makes the binding concrete: the name 'x' is not the value 5, it's an arrow pointing at the value 5. Reassigning x moves the arrow; it never modifies the 5 itself (numbers are immutable anyway). This picture scales to everything in Python.

Keep this image in your head as the series progresses. When we get to mutable objects, function arguments, and shared state, you'll find that almost every confusing behavior dissolves the moment you redraw it as names pointing at objects.

Python's built-in types divide into scalars and containers. The scalars — int, float, str, bool — hold single values. The containers — list, tuple, dict, set — hold collections of other objects. You'll reach for these constantly, and choosing the right one is half of writing good Python.

The key realization is that everything is an object with a type, including the types themselves. There's no special 'primitive' tier hiding underneath like in some languages. An int is a full object you can inspect with type() and call methods on. This uniformity is part of what makes Python so consistent to reason about.

This code slide grounds the abstract type talk in something you can run. Notice there are no type declarations — you don't write `int age` — yet each variable still has a definite type that Python infers from the value you assigned. The type() calls prove it.

Try this in a REPL and mutate it: reassign age to a string and call type() again. Watch the type follow the value, not the name. That's dynamic typing in one experiment, and it's the foundation for understanding why some operations work and others raise TypeError.

The statement-versus-expression split is subtle but useful. An expression is anything that evaluates to a value — you can put it on the right side of an assignment. A statement is a complete instruction that does something — assignments, if-blocks, loops, function definitions. Some lines, like a bare function call, blur the line, but the distinction holds.

Why care? Because it explains errors. You can't write `if x = 5:` because assignment is a statement, not an expression that yields a value to test. Knowing which is which tells you where each piece of syntax is allowed to go.

Execution order in Python is strictly top to bottom, and there's no separate declaration phase that hoists names for you. If you call a function on line 3 that you define on line 10, you get a NameError, because line 3 runs before line 10 exists. This trips up people coming from languages with hoisting.

The practical rule: define before you use. Put your imports at the top, your helper functions next, and your main logic last. This isn't just convention — it's required by the way the interpreter walks your file.

These five points are the compressed takeaway of the whole post. If you remember nothing else, remember that Python is readable and runs line by line, variables are names not boxes, everything is a typed object, expressions make values while statements act, and the interpreter runs your file top to bottom.

Each of these will resurface and deepen in the next four posts. Treat this slide as the index card you'd keep on your desk while the rest of the day fills in the details.

The 'typeless' misconception deserves a direct correction because it leads people astray. Python is dynamically typed, meaning types are checked at runtime rather than declared up front — but it is also strongly typed, meaning it won't silently mash incompatible types together. `"3" + 5` raises a TypeError rather than guessing whether you meant 8 or "35".

Contrast this with weakly typed languages that would coerce one to match the other. Python's strictness here is a gift: it surfaces mismatches as loud errors instead of silent wrong answers, which is exactly what you want when correctness matters.

That wraps the concept post. You now have the vocabulary: language, variable, type, object, expression, statement, interpreter. These words will appear in every post that follows, so the time spent here pays compounding interest.

Tomorrow's angle shifts from 'what' to 'why' — we'll make the case for why mastering these humble basics is the highest-leverage thing you can do before touching any AI framework.