Programming with Python
Kühne Logistics University Hamburg - Fall 2026
The first 40 minutes are the checkpoint. It starts now: the acquirer runs one final audit before signing.
groupby, and telling an honest chart from a misleading oneWhen you’re done: menu → Download → Download Python code → upload the .py to the “Checkpoint 5” assignment on Moodle. No retakes: one sitting.
The green ✅ live checks are provisional. The final grading runs on our side. The two multiple-choice tasks only say “recorded”, not ✅. That’s expected, they’re scored later. And take a breath: everything in it was rehearsed in the labs.
Pens down. The checkpoint is behind you, and so, it turns out, is the startup. Overnight the rival chain MunchCorp stopped competing and made an offer: they’re buying the company.
The lawyers will tell you deals close on the numbers. This one closed on yours. The clean order data you pulled together in the due diligence (Session VIII) and the honest dashboard you built for the pitch (Session IX) are exactly what convinced the acquirer the books were real.
No cliff-edge growth chart with a chopped axis. Just data that survived a second look. That’s why they signed.
Kevin’s job today is to hand over the data room: every file the company ever built. He tapes a note to the folder:
“It’s all here. And it was never anything fancy — every notebook you downloaded all semester was already a plain
.pyfile. Same code, same lines. Open one in a real editor and it just runs.”
That’s the whole reveal, and most of you already suspected it. Those downloads stop being backups today and become the real thing: on your own machine, in a real editor, under your control.
Every acquisition comes with an exit package. Here’s yours: you don’t join MunchCorp. You spin off your own idea and build it.
Let’s get you kitted out.
Over the next weeks you build one real project and present it in the final session.
README.md carries a short AI-disclosure section: which tools you used, what for, and what you verified yourselfPick something you’re actually interested in. You’ll spend real hours on it. Curiosity is the fuel that carries a project past the boring middle.
The project does not have to be flawless. Show that you scoped it honestly, built it in the open, and can explain your own code. That’s the whole bar.
Data analytics dashboard
Bonus: interactive dashboard (streamlit), automated reporting.
Web scraping pipeline
Bonus: multi-source, change detection, alerts.
Simulation study
Bonus: interactive parameters, scenario comparison.
Automation assistant
Bonus: scheduling, notifications, a small UI.
Game
Bonus: levels, high scores, procedural content.
ML-powered app (ambitious: lean on AI)
Bonus: monitoring, A/B comparison.
Your startup spin-off
Bonus: wherever your version wants to grow.
Your own idea: the open door
Right now, in the room:
A good outcome by the end of this block: a one-sentence pitch (“we’re building X that does Y for Z”), a name for the project, and a decision on who owns the shared repo (the owner creates it in the git block; the partner clones). The sentence keeps you honest about scope; the name goes on the repo in a minute.
Before we build anything, the installs from the Session IX homework need to work. In a terminal:
Didn’t work? Don’t burn the session fighting it. Flag it for office hours, pair up with your partner’s working machine, and follow along on the slides for now. Nobody gets left behind.
uv initPick the folder where you keep course work, then create the project (name it after your pitch):
uv init creates main.py, pyproject.toml, .python-version, .gitignore, and README.md.
As long as git is installed (you confirmed that a moment ago with git --version), it also already turns the folder into a git repository: there’s a hidden .git/ inside. You do not run git init yourself. Your project is version-controlled from its very first second.
Here’s the reveal made concrete. Grab a lab .py you downloaded in Part I: we’ll use nb_03_lab_functions.py. Copy it into your project folder first (in Finder/Explorer, or drop it onto Zed’s file tree; dropping on the editor just opens a buffer, it doesn’t move the file). Then open it in Zed: it’s just code. Read it.
The file needs its tools first. Adding a package to a project is one command:
Now run it, no browser required:
uv run uses the project’s own Python and packages. The file that lived in a browser tab all semester now runs on your machine, from your editor. That’s the whole point of today. (The Part-II pandas labs also want uv add pandas and their data file next to them; stick with a Part-I lab today.)
Part III encourages AI. You’ve earned the co-pilot. Connect one provider in Zed following the AI-tools guide (the free Mistral key is the guaranteed path; paste it into Zed’s assistant settings).
The disclosure rule still stands, now in writing: your repo’s README.md says which tools you used, what for, and what you checked yourself. AI drafts; you verify, same reflex as the checkpoint you just sat.
Git has a small vocabulary. Learn these five and you can do everything this project needs:
We’ll do each one live, in your real project repo. Mistakes are cheap when the repo is two minutes old.
Before any push reaches GitHub, your machine has to prove it’s allowed to. Signing in to Zed does not do this; git needs its own setup. You need a (free) GitHub account and the gh tool. Not installed? Get it via the Git Basics page first. Then, once per computer, in a terminal:
Choose GitHub.com, HTTPS, authenticate in the browser, and answer yes to “Authenticate Git with your GitHub credentials?”. Then, once:
Full walkthrough (installing gh, checking it worked) is on the Git Basics page, your at-home reference for all of this.
Auth fighting you? Same rule as the toolchain: flag it, follow along on the slides, and finish the push at home with the Git Basics page, or with us in the supervised sessions. Nobody’s project stalls on a login.
Your uv init folder already has files worth saving. In Zed’s command palette (Cmd/Ctrl+Shift+P):
git: stage all: mark everything as part of the snapshotgit: commit (Cmd/Ctrl+Enter): type a message, save itThis slide is for the repo owner you picked in the pairing block. Partner: watch. You’ll clone in a minute; don’t create your own GitHub repo.
GitHub doesn’t know about your project yet. Three steps, done by the owner:
git: create remote, paste the repo’s HTTPS URL (https://github.com/you/project.git); if it asks for a remote name, use origin (terminal: git remote add origin <HTTPS url>)After this one-time command, every later push is just git: push in Zed (terminal: git push).
The owner invites the partner (GitHub → Settings → Collaborators). The partner gets onto the project by cloning it into a fresh folder, not inside the practice project from the toolchain block (set that one aside; the clone is your real working copy):
git: clone, paste the same HTTPS URLCloning brings the whole project and its history, and sets up the connection automatically. The partner pushes and pulls normally from the first moment. Now both of you pull (git: pull / git pull) to confirm you’re in sync.
Clock ran out? This step keeps: inviting and cloning works just as well at the start of Session XI, with us in the room.
Two people, one repo. Four habits keep it painless:
git: pull first, every session: this alone prevents almost every problem--force, no “force push”, everEverything today (the actions, the terminal equivalents, the setup, and a cheatsheet table) lives on the Git Basics page. When today’s follow-along is a fading memory, that’s the page you reopen.
Between now and then, the repo tells your story. Commit as you go. A steady history is worth more than a heroic final night.
The skill fades if it sits idle. A few honest ways to keep it alive:
print to a real project on your own machineAll the best for your studies and your career. Now go build the thing.
Setting up the toolchain? The Installing Python, AI Tools and Git Basics pages are the reference versions of everything we did live today.
For more, see the literature list of this course.
Lecture X - Tooling, Git and Your Project | Dr. Tobias Vlćek | Home