Master Python for Real Projects

Proof required

Share a GitHub Gist or repo showing the before and after versions of your rewritten program side by side. Share the CSV processing program with a sample input file and its output. Write 150 words on what makes Python idiomatic — what did you remove and why is the shorter version better, not just shorter?

What gets checked

• Before/after comparison is genuine — the after version uses comprehensions, f-strings, or context managers in a place where the before version used a loop, concatenation, or manual file close
• CSV program reads a real file the submitter created (not a downloaded dataset) and produces meaningful output, not just a print of each row
• The 'why shorter is better' reflection names a specific readability or safety improvement — not just 'it's cleaner'

Common mistakes

• Using list comprehensions everywhere even when a regular loop is clearer — Pythonic means readable, not maximally condensed
• Downloading a CSV dataset instead of creating one — the point is to understand the format, not to process big data

Resources

Arena

What a verifier looks for

• Run the CSV program with a file the submitter did not anticipate — add an extra column, include a row with a missing field. Does it crash or handle it gracefully?
• Ask the submitter to explain one specific comprehension in their rewritten code. Can they read it as a sentence? If not, they used it without understanding it.
• Check the 'why shorter is better' reflection — if it only says 'fewer lines', ask them what specific bug or misreading the shorter version prevents.

You'll sign in first, then come straight back here.

Proof required

Share your program code (GitHub repo). The README must list both libraries, explain why you chose each, and show sample output. Write 150 words on how you decided which library to use and what you read to make that decision — the PyPI page, the docs, a tutorial? What would have made choosing easier?

What gets checked

• Second library is genuinely the submitter's choice — not requests again with a different name, and not one of the five most-googled Python libraries (numpy, pandas, matplotlib, flask, django)
• The combined program does something meaningful — not just print(library1_result + library2_result)
• The library selection reflection names the specific docs or resources consulted — not just 'I googled it'

Common mistakes

• Using a tutorial's API (OpenWeatherMap, CoinGecko) because it's the first result — pick an API for a topic you actually care about
• Not reading the library's README before installing it — knowing what a library does before using it is a professional skill

Resources

What a verifier looks for

• Run the program and ask the submitter to change the API endpoint to return a different resource. Do they know how to modify the URL and re-parse the response, or do they need to look everything up again?
• Ask: 'What would happen if the API is down?' If the program has no error handling for failed requests, the milestone is incomplete.
• Check the second library choice — if it's one of the obvious five (numpy/pandas/flask/django/matplotlib) ask why they chose it and whether they considered alternatives.

You'll sign in first, then come straight back here.

Proof required

Share your GitHub repository with the test file included. Share a screenshot of pytest running and showing all tests passing. Share a second screenshot of pytest running after you deliberately broke one function — at least one test must show as FAILED. Write 150 words on one specific bug your tests caught that you wouldn't have noticed otherwise.

What gets checked

• 8 or more tests — not 8 assertions in one test function, but 8 separate test_ functions
• At least one test covers an edge case the submitter didn't originally handle — the test should have failed before they fixed the code
• The 'bug I caught' reflection names the specific input that triggered the bug and what the code was incorrectly doing

Common mistakes

• Writing tests after you know the code works, testing only the happy path — tests that only pass are not tests, they're documentation
• One test function with 8 assert statements — when this fails, you don't know which assertion broke; separate test functions are required

Resources

What a verifier looks for

• Count the test functions — if there are fewer than 8 distinct test_ functions, the milestone is incomplete regardless of assertion count.
• Ask the submitter to add one more test for an edge case they haven't covered. Can they identify an untested path in under 2 minutes? If not, they don't yet understand what their code could do wrong.
• Check the 'bug I caught' reflection — if it describes a bug they already knew about, the test didn't catch it, they wrote the test after fixing it. The bug should have been discovered by the test.

You'll sign in first, then come straight back here.

Proof required

Share your GitHub repository with a sample input dataset you created. Share a README that explains what the pipeline does and how to run it with different inputs. Record a 3-minute screen recording showing the pipeline running on two different input files. Write 200 words on one data quality problem you encountered in your input and how you decided to handle it.

What gets checked

• Pipeline is reproducible — the README explicitly states this and the code has no random elements or time-dependent outputs
• Command-line interface uses argparse or sys.argv — not hardcoded file paths in the code
• The data quality reflection names a specific problem (e.g. dates in two different formats, rows where a required field is empty) and explains the decision made — not just 'I cleaned the data'

Common mistakes

• Using pandas for a pipeline that doesn't need it — if your data fits in memory and doesn't need vectorised operations, the standard library is sufficient and cleaner
• Hardcoding file paths — a pipeline no one else can run is not a pipeline, it's a script

Resources

What a verifier looks for

• Clone the repo and run the pipeline with the sample input. Run it again. Compare the outputs — are they byte-identical? If not, the pipeline is not reproducible.
• Try running with a file path that doesn't exist. Does the program give a useful error or crash with a Python traceback? Useful error handling at the CLI level is a mark of quality.
• Read the data quality reflection — ask the submitter how they decided to handle the problem they described. Was it a deliberate decision or a guess? The answer reveals whether they thought about data integrity or just made it work.

You'll sign in first, then come straight back here.

Proof required

Share the PyPI package page URL. Share evidence that someone other than you installed it (a GitHub issue, a message, a comment — anonymised is fine). Write 200 words on what you chose to package, why that specific functionality is useful to others, and what you would do differently if you were building a package from scratch instead of extracting one.

What gets checked

• Package is installable via pip install — the verifier must be able to install and import it in a fresh virtual environment without errors
• At least one person other than the submitter installed it — not a close friend asked as a favour, but someone who found it or was introduced to it as a genuine user
• The 'what I'd do differently' reflection names a specific structural decision (API design, naming, module organisation) not just 'I'd write better docs'

Common mistakes

• Publishing a package that does something trivially available in the standard library — 'my package wraps print() with a timestamp' will get no real users because it doesn't solve a real problem
• No tests in the package — a published library with no tests is a liability, not a credential

Resources

What a verifier looks for

• In a fresh virtual environment, run: pip install [package-name] then python -c 'import [package]; print([package].__version__)'. If this fails, the package is not properly published.
• Ask the submitter to demonstrate their package solving the problem it claims to solve in under 2 minutes without reading the README. If they can't demo it fluently, they don't know their own API well enough.
• Read the PyPI page as a stranger would — is it clear what the package does in the first two sentences? If you have to read the whole README to understand the purpose, the package description needs work.

You'll sign in first, then come straight back here.