Python: A Practical Course with Ethan Cho

Start with the purpose

Place Python inside a small but realistic software or digital-safety task. Name the result a learner is trying to produce and the constraints that make the skill useful.

How Python actually works

These are the load-bearing ideas. Everything later in the course is an application of one of them, so it is worth reading slowly and returning to when something stops making sense.

• Default arguments are evaluated once. A default value is created when the function is defined, not on each call, so a mutable default such as a list persists between calls and quietly accumulates state. The standard fix is to default to None and construct the container inside the function body.
• Identity is not equality. The == operator compares values, while `is` compares object identity. Python caches small integers and short strings, so `is` sometimes appears to work and the resulting bug is intermittent; reserve `is` for None, True and False.
• Dictionaries preserve insertion order. Since Python 3.7 the language guarantees that dicts iterate in insertion order, a behaviour that was only an implementation detail in 3.6. Sets carry no such guarantee, so never rely on set iteration order being stable.

Misconceptions worth clearing early

Each of these is common, understandable, and expensive to leave in place. Recognising them now saves rework later.

• Modifying a list while iterating over it. The loop appears to visit every element, so removal inside it looks safe. Fix: Iterate over a copy of the list, or build a new list with a comprehension and rebind the name.
• Catching bare except. It looks like a way to make code robust against every possible failure. Fix: A bare except also swallows keyboard interrupts and exit calls. Catch Exception, or better, the specific error class you expect.
• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.

Build the mental model

Connect the key terms as a process rather than a word list. Use this sequence: decompose the problem, build one testable step, inspect the result, and debug deliberately.

Catch the common miss

Compare a surface-level attempt with one that shows correct behavior, readable structure, useful tests, and an explained decision. Explain the single difference that matters most.

Watch the whole process

Trace a model from the initial prompt to a working program, configuration, or technical walkthrough. Mark each point where the learner must observe, choose, or verify rather than act automatically.

Worked example: Predicting the output order of an event-loop snippet

Follow each step and predict the next before you read it. Predicting first is what turns a demonstration into practice.

1. A script logs A, then schedules a timer logging B with zero delay, then a resolved promise logging C, then logs D directly.
2. The synchronous statements execute first in source order, printing A and then D.
3. The call stack empties, so the microtask queue drains next and prints C.
4. Only afterwards does the event loop pick up the timer macrotask and print B, giving the order A, D, C, B.

A setTimeout of zero does not mean immediately; it means after the current task and after every pending microtask.

Where this usually goes wrong

Watch for these while you work through the demonstration rather than afterwards.

• Expecting an async function to return its value directly. The body reads like ordinary sequential code, so the return looks ordinary too. Fix: An async function always returns a promise. Await the call, or chain a then handler onto it.
• Losing the value of this when passing a method as a callback. The method reference is handed over without its receiver object attached. Fix: Wrap it in an arrow function or bind the method, since arrow functions take this from the enclosing scope.
• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.

Practice with scaffolding

Repeat the model with one detail changed. Keep the prompts visible and say or write the reason for each choice before continuing.

Check before feedback

Use correct behavior, readable structure, useful tests, and an explained decision as the quality test. Make one self-correction before asking the tutor to review the result.

Read the situation

Translate the scenario into a clear task. Separate facts, assumptions, constraints, and information that is interesting but not relevant to APIs.

Choosing well under real constraints

Applied work is mostly judgement under limits: less time, less information, and more competing goals than a textbook example allows. These are the decision rules that hold up in practice.

• Two approaches both look workable: Choose the one you can test more easily; testability compounds faster than elegance.
• The task feels too large to start: Cut it until one piece can be finished and verified in under an hour, then build outward.
• You are unsure whether something is a real bug: Write the smallest input that reproduces it; if you cannot reproduce it, you cannot claim to have fixed it.

Reading the situation before acting

Before choosing an approach, state three things explicitly: what result the situation actually requires, which constraints are fixed rather than preferences, and what evidence would tell you the approach is working. Skipping this step is the most common reason competent work solves the wrong problem.

• Default arguments are evaluated once. A default value is created when the function is defined, not on each call, so a mutable default such as a list persists between calls and quietly accumulates state. The standard fix is to default to None and construct the container inside the function body.

Practitioner notes

Small pieces of working knowledge that rarely appear in introductory material.

• Search the standard library before writing a helper. collections.Counter, itertools.groupby and functools.lru_cache replace a surprising amount of hand-rolled code.
• Use one virtual environment per project and pin your dependencies, so a global package upgrade cannot silently break code that worked yesterday.

Compare real options

Generate two workable approaches and test both against the purpose. Do not hide the tradeoff; name what each option improves and what it gives up.

Make the reasoning visible

Produce a working program, configuration, or technical walkthrough and attach a short decision note. The note should make the result auditable, not merely confident.

Use the rubric, not a feeling

Review the work for correct behavior, readable structure, useful tests, and an explained decision. Record evidence for each judgment so feedback points to something observable.

Diagnostic checklist

Run this before you revise anything. Diagnosing first prevents the common failure of polishing the parts that were already fine.

• Check: Modifying a list while iterating over it — is this present in your work?
• Check: Catching bare except — is this present in your work?
• Check: Changing several things at once when something breaks — is this present in your work?
• Check: Reading code without running it — is this present in your work?

The quality bar

This is what finished work looks like in this field. Use it as the standard for your revision rather than a general sense of improvement.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Diagnose before editing

Name the symptom, then ask what decision or missing step produced it. Choose the cause you can address rather than changing everything at once.

Revise and compare

Make one purposeful revision and compare the two versions. Keep the change only if it improves the intended result without creating a larger problem.

Define a finishable brief

Choose a specific audience, result, and boundary for the Software architecture capstone. Reduce scope until the project can be finished and reviewed in one focused cycle.

Bringing the parts together

A capstone is judged on coherence, not on the number of techniques it includes. Return to the core ideas and make sure the work demonstrates them rather than decorating them.

• Default arguments are evaluated once. A default value is created when the function is defined, not on each call, so a mutable default such as a list persists between calls and quietly accumulates state. The standard fix is to default to None and construct the container inside the function body.
• Identity is not equality. The == operator compares values, while `is` compares object identity. Python caches small integers and short strings, so `is` sometimes appears to work and the resulting bug is intermittent; reserve `is` for None, True and False.
• Dictionaries preserve insertion order. Since Python 3.7 the language guarantees that dicts iterate in insertion order, a behaviour that was only an implementation detail in 3.6. Sets carry no such guarantee, so never rely on set iteration order being stable.

Standards that make the work credible

These are the marks of work that would be taken seriously by someone who does this professionally.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Practitioner notes

Small pieces of working knowledge that rarely appear in introductory material.

• Search the standard library before writing a helper. collections.Counter, itertools.groupby and functools.lru_cache replace a surprising amount of hand-rolled code.
• Use one virtual environment per project and pin your dependencies, so a global package upgrade cannot silently break code that worked yesterday.

Build with checkpoints

Plan foundation, first draft, verification, and revision milestones. At each checkpoint, save evidence instead of relying on memory.

Present and continue

Present a working program, configuration, or technical walkthrough with a concise rationale. Use the final rubric to choose one strength to retain and one next practice target.