Python Programming

This is a demonstration, not a question. A complete one is a CLI of roughly 150–300 lines written from an empty file: it reads input, validates it, dispatches to functions in more than one module, persists data to disk, handles the missing and malformed file cases, and has tests you have watched fail. If you reached for generated code at any point, the demonstration has not happened yet.

A mutable object can be changed in place after it is created; an immutable one cannot, so any change produces a new object. Lists, dictionaries and sets are mutable; strings, integers and tuples are immutable. It matters when a value is shared: passing a mutable object into a function lets that function change what the caller still holds, while passing an immutable one cannot.

A list is an ordered, mutable sequence that allows duplicates. A tuple is the same shape but immutable, which is why it can be used as a dictionary key. A set is unordered and holds each value once, making membership tests cheap. A dictionary maps keys to values and gives near-constant lookup by key. Choose from the question you ask most: order, uniqueness, or lookup by key.

Arguments are the values a function receives; the return value is the single result it hands back. A function that prints has produced output but returned nothing, so nothing can be tested or reused. Returning a value lets the caller decide what to do with it, which is what makes the function composable and testable.

An exception is a signal that normal execution cannot continue, raised at the point the problem is detected and handled somewhere up the call stack. Catch the specific exception you anticipated and let the rest propagate, because a bare catch-all hides bugs. Validation prevents a bad state; exception handling responds to one that has already occurred.

A module is a single Python file; a package is a directory of modules. Importing executes the target module once and binds its names into the importing namespace. Whether an import resolves depends on where Python believes the project root is, which is why the same code can import successfully from one directory and fail from another.

A class is a template describing what data an instance holds and what it can do. An object is one instance made from that template, with its own attribute values. Reach for a class when data and behaviour travel together; a plain dictionary is still the right answer when there is no behaviour to attach.

Serialization converts in-memory objects into a form that can be written to disk, and deserialization reads it back. JSON preserves structure and basic types; CSV is text with conventions and returns every field as a string. Both need the missing-file and malformed-content cases handled, because both will occur.

Runtime code is what the program does; test code is what proves it does it. Tests are not shipped as behaviour, they are run to check behaviour, and they must be able to fail. A test you have never watched fail is evidence of nothing, which is why you break the implementation deliberately before trusting a green run.

A commit records a snapshot of the tracked files plus who made it, when, and why. `.gitignore` lists paths Git should not track, such as virtual environments, caches and anything holding a secret. It exists because the repository should contain the source of your project and nothing that can be regenerated or must never be shared, and because history keeps whatever you commit even after a later commit deletes it.

Every subject in this stage has review questions. The condition is met when you can answer them out loud, without notes and without looking anything up, in your own words rather than a recited definition. An explanation you can only give with the material open is recognition, not recall.

Complete means each exercise satisfies its stated requirements and its done-when criteria, not that you attempted it. Where an exercise says you should be able to explain or defend something, that explanation is part of completing it. A stage whose source lists no exercises meets this through its owned project milestone instead.

Works means it runs end to end from a clean checkout, on the inputs it was built for, with the failure cases it claims to handle actually handled. It is not a notebook that produced a result once. Someone else following your README should be able to run it without asking you a question.

There is something that would fail if the behaviour regressed, and you have watched it fail. That can be automated tests or a written verification procedure with recorded results, depending on what the stage produces. A test that has only ever passed is evidence of nothing.

The README says what the project is, how to install, run and test it, and why it is built the way it is: the choices you made, the alternatives you rejected, and what you deliberately left out. A list of commands with no reasoning does not meet this condition.

Delete the central piece and write it again from an empty file, without your previous version, a tutorial, or generated code in front of you. It does not have to be identical, it has to work and you have to be able to explain every line. This is the condition that separates having finished from being able.

Record a gate exam and score yourself honestly against the dimensions the roadmap defines: recall, implementation, debugging, testing and design judgment. Elapsed time, hours watched and completed resources count for nothing here. Checking the boxes without a recorded exam does not open the gate.

Ask an AI reviewer to examine the work against this stage's concepts and report foundational misunderstandings, not style. A foundational blocker is a misconception that later stages would build on, such as leakage, a broken abstraction, or an explanation that is confidently wrong. Nothing in that class may remain open when you pass.