Python Programming

Most Python courses teach the syntax and stop. That is the part you could have read in a weekend. What separates someone who writes Python from someone a team hires is different: knowing why a "copy" of a list changed the original, why fitting a scaler before splitting inflated a score, why a loop that works on ten thousand rows dies on ten million, and why the notebook that produced last week's number cannot produce it again.

This course spends three sessions on the basics and the remaining twenty-seven on that. It is a starting point for three different directions — Python backend engineering, data analytics, and machine learning — and it is built so that you leave with a working proof of concept for each, over one dataset, so each build stands on the previous one.

Participation requirements

Some prior programming experience is strongly recommended — in any language. The basics are compressed into the first three sessions specifically so the rest of the course can go deeper, and a learner meeting variables and loops for the first time will find that pace difficult. If you have never programmed at all, DTA-16 C Programming or DTA-01 Professional Developer Foundations is the better first step; neither is a formal prerequisite.

Learners need regular access to a 64-bit Windows, Linux or macOS computer with at least 8 GB of memory, basic file-and-folder skills, and permission to install the course toolchain. Plan approximately 45–60 minutes of practice after most sessions, and up to two hours between build sessions. This practice is recommended for fluency and is not counted in the 60 guided hours.

Who should choose a different course

This course is not intended for experienced Python engineers who already write typed, tested, packaged code and use pandas and scikit-learn daily. It is a launch pad, not a specialisation.

It does not teach deep learning, neural network architectures, PyTorch or TensorFlow, computer vision, reinforcement learning, MLOps platforms, distributed computing with Spark, data engineering pipelines and orchestration, or production model monitoring at scale. Each of those deserves its own programme, and each assumes what is taught here. What this course gives you is the Python, the data discipline and the evaluation judgment that every one of those paths takes for granted.

Deep learning specifically is out of scope by design. A learner who cannot yet frame a problem, split data without leaking it or beat a trivial baseline will not benefit from a neural network; they will get a worse result they cannot diagnose.

Python version and toolchain

The course is taught on a current stable Python 3.12 or later. Environments and dependencies are managed with uv from the first session, because a reproducible environment is not an advanced topic — it is the difference between code that runs on one machine and code that runs. ruff handles linting and formatting, and a type checker runs from the module in which type hints are introduced.

Library choices reflect what teams actually use: FastAPI and pydantic for services, NumPy and pandas for data, DuckDB for analytical queries over files, matplotlib for figures, scikit-learn for modelling, and pytest throughout. Polars, MLflow and pandera are demonstrated as clearly-labelled awareness so learners recognise them in a real codebase without being assessed on them.

Notebooks are used where exploration genuinely belongs in a notebook, and modules are used everywhere else. Learners are taught to move code out of a notebook as soon as it is worth keeping, which is the habit most self-taught analysts are missing.

Development environment options

1. Recommended: Visual Studio Code with the Python and Jupyter extensions, ruff, and a type checker. Free, widely used, and it exposes the debugger and the terminal rather than hiding them.
2. Alternative: PyCharm with a configured interpreter. A more integrated project, refactoring and debugging experience, with higher system requirements, used under an appropriate JetBrains licence.

How each session works

Each two-hour session follows a consistent rhythm:

• approximately 35 minutes of concept explanation and live demonstration
• approximately 70 minutes of guided and independent coding
• approximately 15 minutes of review, debugging discussion or a short formative learning check

The balance changes during build sessions, when most of the time is used for implementation, review and correction.

Three builds, one dataset

The course is organised in three parts of ten sessions. Each part ends in a proof of concept that a learner can show to an employer, and all three use the same Campus Transit domain — stops, routes, scheduled and actual trip times, passenger counts — so nothing is thrown away. The domain needs no specialist knowledge, and the brief supplies acceptance criteria and deliberately imperfect sample data without supplying the implementation.

Build one — the backend service (sessions 1–10)

A documented FastAPI service over stops, routes and trip records: pydantic request and response models, validation errors that say what is wrong, SQLite persistence with parameterised queries, dependency injection, automatic OpenAPI documentation, a pytest suite against the test client, and a pyproject.toml that lets anyone clone the repository and run it.

This is the deliverable for someone heading towards Python backend work, and it is the service the third build later deploys a model into.

Build two — the analytics proof of concept (sessions 11–20)

A reproducible punctuality and load analysis. The input is deliberately dirty: duplicated rows, missing timestamps, inconsistent route codes, mixed date formats. The output is a written report with charts, findings and stated limitations, produced by a pipeline that can be rerun from raw data with one command and return the same numbers.

Every transformation must be justified in writing. Deciding what to do with a missing value is a judgment with consequences, and treating it as a formatting detail is how analyses become wrong quietly.

Build three — the machine learning baseline (sessions 21–30)

A delay-prediction baseline built the way it is built professionally: the problem framed in writing, the target defined, the split justified, the metric chosen and defended, a trivial baseline established first, then scikit-learn pipelines cross-validated without leakage, several model families compared, a decision threshold chosen for a stated cost of error, and permutation importance used to explain what the model actually relied on.

The chosen pipeline is then serialised, versioned, and served behind the API from build one. The documentation must state what the model cannot do. A baseline you can defend and explain is worth more to an employer than a higher score you cannot account for.

Recommended depth and boundaries

Language depth

Closures, decorators, generators, the data model, dataclasses and type hints are required and assessed, because they are what separates readable Python from working Python. Metaclasses, descriptors, __init_subclass__, C extensions and bytecode internals are out of scope. The GIL is explained operationally — what it does and does not prevent — rather than formally.

Concurrency

async and await are taught in the context of the API, along with the honest answer to when concurrency helps: waiting on the network, not computing in Python. Threading, multiprocessing and the trade-offs between them are covered as awareness. Distributed execution is not covered.

Data work

pandas is taught to the level of defending your transformations, not memorising the API. Learners must be able to choose between pandas, SQL and DuckDB for a stated question and justify it. Streaming ingestion, orchestration tools and warehouse modelling belong to data engineering.

Machine learning

Framing, splitting, leakage, pipelines, cross-validation, metric selection, threshold choice and interpretation are required and assessed — these are what practitioners get wrong. Model breadth stops at gradient boosting and clustering. Neural networks, hyperparameter search at scale and feature stores are not covered.

Large language models

One session, deliberately. Learners call an LLM API from Python, validate its output as data, measure cost and latency, and compare it against a classical model on the same labelled sample. The purpose is judgment about when to reach for one, not prompt technique.

Assessment and completion

Each session includes a formative learning check. The required final quiz is delivered in Moodle; session checks may also be assembled there after platform import review. Course completion requires:

• at least 80% attendance
• at least 60% on the required final quiz, with a maximum of two attempts

For the pilot batch, attendance and the final quiz are recorded and verified manually by the trainer. Automated tracking arrives with the learning platform; the completion criteria above are the same either way.

The three builds are reviewed and demonstrated as applied learning evidence, but they are not an additional completion gate for this pilot. The completion record confirms the attendance and knowledge-check criteria above; build evidence is recorded separately and does not claim an independently certified level of professional capability. This course does not provide a certification.

Learning materials

Active enrolled learners receive session study guides, starter projects, the deliberately imperfect datasets used in the builds, exercises, the course quick reference and interview-preparation material. Approved session recordings may be provided when a batch records them with the required notice, consent, review and access controls. Learner material is shared through restricted access. Study material is view-only where the platform supports it; starter code and exercise data are downloadable so learners can run and edit a personal working copy. Trainer plans, source presentations, solutions and question rationales remain private.

Interview-preparation material

Learners receive supplementary material covering the Python, pandas and machine-learning questions most commonly asked of early-career candidates, together with code-reading exercises and "what does this print" drills of the kind used in written screening rounds. It will be exported to an accessible participant format before release. This material supports revision; the course does not promise interview or employment outcomes.