WAIT — Slowing — last commit 4mo ago

• Last commit 4mo ago
• 5 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• WTFPL licensed
• CI configured
• ⚠ Slowing — last commit 4mo ago
• ⚠ Non-standard license (WTFPL) — review terms
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

wtfpython is an educational repository of curated Python code snippets that demonstrate counter-intuitive, surprising, or lesser-known behaviors in Python's runtime and type system. It serves as both a learning resource and challenge to understand Python's internals through hands-on examples, with each snippet paired with detailed explanations of why the output is unexpected. Single-directory structure with Markdown-driven content: README.md contains the main body of examples in a table-of-contents format; snippets/ directory holds individual .py example files (e.g., snippets/2_tricky_strings.py); translations/ tree mirrors the structure for localized versions (ru-russian/, fa-farsi/); irrelevant/ holds build tooling (notebook_generator.py, insert_ids.py) and Jupyter artifacts.

Python developers at all levels—especially intermediate programmers wanting to deepen their understanding of Python's memory model, string interning, mutable defaults, and type coercion. Also useful for interviewers and interviewees preparing for technical discussions on Python semantics.

Highly mature and actively maintained: the project has significant community engagement (translations into 7+ languages, an interactive website at wtfpython-interactive.vercel.app, and a Google Colab notebook). CI is configured via .github/workflows/pr.yml and .travis.yml. However, the actual last-commit date is not visible in the provided data, so recency cannot be confirmed.

Low risk for a documentation/educational project. The main risks are (1) single-maintainer dependency (satwikkansal), (2) no Python package dependencies to manage—it's purely Markdown and example code files, and (3) no runtime services or production deployment surface. The .pre-commit-config.yaml and .markdownlint.yaml show quality gates are in place.

The project is actively maintained with a structured contribution workflow: .github/ISSUE_TEMPLATE/ includes templates for bug reports, new snippet proposals, and translation requests; .github/PULL_REQUEST_TEMPLATE/ has separate workflows for common changes, new snippets, and translations. A recent major revision exists (referenced in the README's 'PS' section with tagged releases).

git clone https://github.com/satwikkansal/wtfpython.git && cd wtfpython && python --version (Python 3.x required based on content). No install step needed—read README.md in your editor, or run individual .py files from snippets/ with python snippets/2_tricky_strings.py to see the behavior.

Daily commands: No server or build step. To explore: (1) read README.md directly in GitHub or clone locally; (2) run individual snippets: python snippets/2_tricky_strings.py; (3) open irrelevant/wtf.ipynb in Jupyter or Google Colab for interactive execution; (4) visit https://wtfpython-interactive.vercel.app for the web UI.

• README.md: Core content file containing all examples, explanations, and Table of Contents; this is the main deliverable of the project
• snippets/: Directory holding individual Python example files referenced and explained in README.md; each .py file demonstrates a specific WTF behavior
• .github/workflows/pr.yml: Defines CI/CD pipeline for pull request validation, ensuring code quality and consistency of new contributions
• .github/ISSUE_TEMPLATE/new_snippet.md: Template guiding contributors on how to propose new examples with clear structure and requirements
• CONTRIBUTING.md: Contribution guidelines for the community, covering how to add snippets, translations, and bug reports
• irrelevant/notebook_generator.py: Build tool that auto-generates the Jupyter notebook (irrelevant/wtf.ipynb) from README.md snippets for interactive exploration
• translations/: Localized versions of the project in multiple languages; each language folder mirrors the README.md structure for community accessibility

To add a new snippet: (1) create or edit a .py file in snippets/ (e.g., snippets/3_your_topic.py) with the counter-intuitive code; (2) add an entry to the Table of Contents in README.md with the snippet number and title; (3) write the explanation section below your entry following the existing format (structure is: Title → Example → Output → Explanation). For translations, mirror changes in translations/[lang-code]/README.md. Use the GitHub issue template .github/ISSUE_TEMPLATE/new_snippet.md for proposals.

No hidden traps typical of software projects—this is primarily documentation. However, note: (1) The .pre-commit-config.yaml is present but the actual hooks (e.g., markdownlint) must be installed locally with pre-commit install if you plan to commit; (2) Notebook generation (irrelevant/notebook_generator.py) likely requires Python + Jupyter dependencies if you intend to regenerate wtf.ipynb; (3) Mixed tabs and spaces exist (mixed_tabs_and_spaces.py is intentional as an example, but watch for actual linting with .markdownlint.yaml).

• String Interning — wtfpython prominently features string interning (images/string-intern/ contains visual explanations); understanding when Python reuses string objects vs. creating new ones is critical to avoiding identity (is) vs. equality (==) bugs
• Mutable Default Arguments — A classic Python gotcha where mutable objects (lists, dicts) as function defaults are created once and shared across all calls; this is a frequent source of subtle bugs and is heavily featured in wtfpython examples
• Python's Global Interpreter Lock (GIL) — Explains why some surprising behaviors occur in multi-threaded Python code; understanding GIL semantics helps predict and debug concurrency-related WTFs
• Object Identity and Reference Semantics — Python's is operator checks identity (same object in memory), not equality; this distinction is central to many wtfpython examples that trick programmers familiar with other languages
• Name Binding and Scope Resolution (LEGB Rule) — Python's scoping rules (Local, Enclosing, Global, Built-in) create unexpected variable binding behaviors, especially with closures and nested functions—a frequent source of WTF moments
• Shallow vs. Deep Copy — The difference between shallow copy (list.copy(), dict.copy()) and deep copy (copy.deepcopy()) is often misunderstood and leads to surprising mutations of nested mutable objects
• Bytecode and Code Objects — Python compiles source to bytecode before execution; understanding code objects and dis module output clarifies why certain optimizations (constant folding) and behaviors occur

• donnemartin/system-design-primer — Complementary educational repository using similar Markdown + code structure to teach complex concepts through examples and deep dives
• TheAlgorithms/Python — Community-driven Python learning repo with similar structure (organized by topic, multiple translations, contribution templates) but focused on algorithm implementations rather than language gotchas
• gvanrossum/cpython — Official CPython source code repository; essential for understanding the internals behind the WTF behaviors explained in this project (memory management, string interning, etc.)
• python/cpython-docs — Official Python documentation; referenced as the authoritative source for language semantics and behavior discussed in wtfpython's explanations
• reuben/interpy — Similar educational project exploring Python internals through interactive code, targeted at learners wanting deeper understanding of the interpreter

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create automated snippet verification workflow in .github/workflows

The repo contains Python snippets in snippets/ directory but lacks a CI workflow to verify that all snippet files are syntactically valid and executable. Currently only .travis.yml exists (legacy). Add a GitHub Actions workflow to run each snippet file and validate outputs match documentation.

• [ ] Create .github/workflows/test-snippets.yml to run pytest or direct execution on all files in snippets/ directory
• [ ] Verify snippets/2_tricky_strings.py and other snippet files execute without syntax errors
• [ ] Add output validation or at least syntax checking as a required status check
• [ ] Reference this workflow in CONTRIBUTING.md to inform contributors about snippet testing

Add pre-commit hooks configuration validation and enforcement

The repo has .pre-commit-config.yaml and .markdownlint.yaml but these tools aren't clearly documented in CONTRIBUTING.md. New contributors won't know to use them. Add setup instructions and a validation script to ensure consistency.

• [ ] Update CONTRIBUTING.md with 'Local Development Setup' section explaining pre-commit installation (pre-commit install)
• [ ] Document that .markdownlint.yaml enforces markdown standards and why (MD013 disabled in README, etc.)
• [ ] Add a simple setup.sh or document noxfile.py usage for local validation
• [ ] Consider adding a .pre-commit-config.yaml enhancement to include markdown linting by default

Create structured test suite for snippet explanations and edge cases

The snippets/ directory has Python files but no corresponding test files that verify the actual outputs described in README.md match reality. This ensures documentation accuracy across Python versions and prevents documentation drift.

• [ ] Create snippets/tests/ directory with test files matching snippets/ structure (e.g., test_2_tricky_strings.py)
• [ ] Add pytest fixtures to capture actual output from each snippet and compare against documented behavior
• [ ] Document in CONTRIBUTING.md how to add tests when submitting new snippet PRs via PULL_REQUEST_TEMPLATE/new_snippet.md
• [ ] Run tests in the GitHub Actions workflow from the first suggestion to gate snippet additions

• Add a new snippet explaining Python's descriptor protocol behavior (e.g., property getters/setters with mutable defaults) and contribute snippets/3_descriptors.py with corresponding README.md explanation section.
• Expand test coverage for existing snippets by creating a pytest suite in a tests/ directory that verifies each .py file in snippets/ produces the documented unexpected outputs—currently there are no .py test files visible.
• Translate README.md and key snippets into an additional language (e.g., Japanese, Portuguese, or Turkish) by creating a new folder in translations/[lang-code]/ following the Russian or Farsi template structure.

This is a low-risk educational repository focused on demonstrating Python quirks and surprising behaviors. No critical or high-severity vulnerabilities were identified. The codebase contains no external dependencies requiring security scrutiny, no hardcoded secrets, and no infrastructure/Docker exposure risks. The repository structure is clean with proper CI/CD configuration (.github/workflows, .pre-commit-config.yaml) and community guidelines in place. The primary security posture is excellent for an educational resource of this nature.

• Low · Mixed Tabs and Spaces in Python File — mixed_tabs_and_spaces.py. The presence of 'mixed_tabs_and_spaces.py' in the root directory suggests inconsistent indentation practices. While this file appears to be intentional (part of a Python quirks/education repository), it could serve as an example of poor coding practices that might be inadvertently copied. Fix: Ensure this file is clearly documented as an educational example and is not included in production code. Consider adding a prominent comment explaining its purpose.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/satwikkansal/wtfpython shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live satwikkansal/wtfpython repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/satwikkansal/wtfpython.

What it runs against: a local clone of satwikkansal/wtfpython — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in satwikkansal/wtfpython | Confirms the artifact applies here, not a fork | | 2 | License is still WTFPL | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 145 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of satwikkansal/wtfpython. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/satwikkansal/wtfpython.git
#   cd wtfpython
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of satwikkansal/wtfpython and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "satwikkansal/wtfpython(\\.git)?\\b" \\
  && ok "origin remote is satwikkansal/wtfpython" \\
  || miss "origin remote is not satwikkansal/wtfpython (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(WTFPL)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"WTFPL\"" package.json 2>/dev/null) \\
  && ok "license is WTFPL" \\
  || miss "license drift — was WTFPL at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 145 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~115d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/satwikkansal/wtfpython"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.