FlyPython: a Python course repository where verify.py decides when you are done

What FlyPython solves, and who it is written for

Most Python learning material ends at reading. FlyPython ends at a claim code. The repository is a set of challenge courses, each with a TASK.md contract and a verify.py script. You solve the contract with a coding agent as the tool, then the script decides whether the work counts. That is the whole premise, and it is a narrow one: the README says the goal is to move from "the agent wrote code" to "a user outcome is verified."

The audience is therefore not absolute beginners. It is people who already have a coding agent that can run commands and reach the network. The README lists Claude Code, the Codex app, Cursor, DeepSeek Harness, Kimi Code and ZCode, and states plainly that chat-only web AIs cannot run these courses. If your agent cannot execute a shell command, nothing here works.

The repository is bilingual, with README.md and README_cn.md, and it separates two roles. The repository owns the reviewed source content and data. The website at flypython.com turns pinned versions into a browsable experience. The README is explicit that pinning a commit and serving it proves release delivery, not learner outcomes or paid demand.

The verify.py loop: claim codes, attestations and what [pending] means

The mechanism is a script per course folder. Run python verify.py after each change. According to the README, it tests only starter/. Three states come back. [open] means the task is unfinished. [passed] gives a claim code. [pending] is a reflection checkpoint, which is not a test result at all but a question you have to answer in prose.

Reflection checkpoints do not resolve on their own. You answer that lesson's questions and then run python verify.py --attest l01, repeating for each completed reflection, to get its code. The current master adds what the README calls learner verifier v2: tests must pass and reflection checkpoints must be explicitly confirmed with --attest. So a course can be half-passed and half-attested, and only passed and attested codes are meant to be submitted, through your agent or the dashboard.

There is a versioning detail worth noticing. check --json is described as the versioned v2 interface, while progress --json remains for older signed-receipt integrations. That is a compatibility seam, and it tells you the receipt format has already changed once at version 0.1.1.

Installing FlyPython and running your first course

The fastest path does not involve cloning anything. You install the FlyPython Skill in your agent, then paste one sentence. The README gives this exact instruction, and the agent authorizes you with a one-time link rather than a password, fetches the course files itself and drives the challenges.

Read https://flypython.com/skills/flypython/SKILL.md and start the FlyPython course `da-eda`.

The SKILL.md URL is the only thing the agent needs. If you are new to driving an agent at all, the README points to a tool course for your specific agent, such as courses/hands-on-python-with-claude-code/COURSE.md or courses/hands-on-with-openai-codex/COURSE.md.

Maintainers can reproduce an example locally without any agent. This is the path to use if you want to see the verification model before trusting it with a course.

git clone https://github.com/flypythoncom/python.git
cd python
python examples/product-slug/verify.py starter --expect-failure
python examples/product-slug/verify.py solution

The first command is expected to fail, which is the point: the starter is deliberately unfinished. The second runs the solution and should pass. The same pattern repeats inside courses/ with python verify.py. Expect [open] on a fresh starter, [passed] once the contract is met, and [pending] for any reflection checkpoint you have not yet attested.

For the whole repository, the Makefile exposes the maintenance commands. make check runs catalog, export, readme, manifest, example and course checks together; make test runs pytest; make verify, make courses and make paths each run one verifier.

make check
make test

Where FlyPython gets in the way

The agent requirement is a hard gate, not a preference. The README says chat-only web AIs cannot run these courses. That rules out a large share of how people actually use AI today, and it means the first thing you must verify is your own tooling, not the course.

The verifier is also narrower than it sounds. It tests only starter/, so work you do elsewhere in a course folder is not what produces a claim code. And --attest is a human step: the script cannot tell whether your reflection answer was thoughtful, only that you confirmed it. Anyone treating an [attested] code as evidence of understanding is reading more into it than the tool provides. The README itself draws the line at release delivery rather than learner outcomes.

The repository is explicit that the website's payment and email operations still have separate acceptance gates. If you were evaluating FlyPython as a product rather than a course repository, that sentence is the boundary of what is claimed to work.

Finally, the licence field is NOASSERTION at the repository level while pyproject.toml declares license = { text = "MIT" }. Those two do not agree, and anyone redistributing the content should read LICENSE directly rather than trusting either metadata field.

FlyPython versus a conventional Python tutorial site

A conventional tutorial site gives you prose, an embedded interpreter and a green checkmark when sample output matches. FlyPython inverts that. There is no interpreter in the browser. The unit of progress is a claim code emitted by a script running against your own files, and the agent is the thing that types.

The practical difference shows up in what each is good at. A tutorial site is better when you want to look something up, try one expression, and leave. FlyPython is better when you want a task contract, a failing starter and an objective signal that the contract is met. It is also worse at the first ten minutes, because you must install a Skill and authorize an agent before anything runs.

The second difference is the receipt. FlyPython's check --json is a versioned interface with signed-receipt integrations behind progress --json. A tutorial site has no equivalent, and a plain GitHub exercise collection usually has no verifier at all. That is the actual distinction: not the Python content, which is widely available, but the verification layer wrapped around it.

Maintenance, releases and what upgrading costs you

The last push to master was on 2026-09-19, and the repository is not archived. The README pins that state precisely: master is 39a3e79be939f491ac3c779494bf5c655c5588a0 and the package version is 0.1.1, following the immutable v0.1.1 tag. The recent release v0.1.1 is dated 2026-09-14 and is described as a companion release for website v0.1.0.

That pinning is the maintenance story. FlyPython.com serves one exact commit in production, so the repository and the site can drift only deliberately. For a consumer of the courses, an upgrade means moving to a new tag and re-running the verifiers, because v0.1.1 introduced verifier v2 and the --attest requirement. Courses completed under an earlier verifier may not carry over cleanly, and the README does not document a migration path for existing claim codes.

The dependency surface is small: requires-python is >=3.11, and the runtime dependencies are PyYAML, requests and urllib3, with the lock file pinning PyYAML 6.0.3, requests 2.32.5 and urllib3 2.6.3. The dev extra adds pytest, jsonschema, ruff, mypy and type stubs, plus pandas 2.3 and matplotlib 3.10 for the data courses. That is a modest footprint for a repository that also ships a catalog, a radar queue and a content manifest.

On licensing: pyproject.toml declares MIT, the repository licence field reports NOASSERTION, and the LICENSE file is the authority. This is not legal advice, but if you plan to reuse course text or catalog data in your own product, reconcile those three before you build on them.

Editorial conclusion

Adopt FlyPython if you already drive a command-running coding agent and want a graded Python task loop with objective checkpoints, or if you maintain the catalog and need make check to stay green. Do not adopt it if your only AI is a chat window, or if you want a reference manual rather than tasks. Before committing, run python verify.py in one course folder and watch for [open], [passed] and [pending], then read pyproject.toml to confirm Python 3.11 or newer and the three runtime dependencies PyYAML, requests and urllib3.

Frequently asked questions

Official sources

1. flypythoncom/python on GitHub
2. Issues
3. Project website
4. README
5. Releases