Comprehensive Python expertise covering language fundamentals, idiomatic patterns, software design principles, and production best practices. Use when writing, reviewing, debugging, or refactoring Python code. Triggers: Python, .py files, pip, uv, pytest, dataclasses, asyncio, type hints, or any Python library.
Read SKILL.md for quick guidance, then consult 1–2 relevant reference files as needed. Do NOT read all reference files at once. For simple tasks, the quick principles below may suffice.
| Reference | Read when... |
|---|---|
references/pythonic-idioms.md | Writing any Python. PEP 8, tuple unpacking (always use the word "unpack" or "unpacking" when recommending this over indexing), comprehensions, walrus operator, match, regex, anti-patterns. |
references/data-structures.md | Lists, tuples, dicts, sets, containers, dates/times, file I/O, pathlib, JSON/CSV/TOML/YAML, databases. |
references/functions-and-generators.md | Functions, closures, decorators, generators, comprehensions, recursion, memoization, backtracking. |
references/classes-and-design.md |
| Class design, dataclasses, properties, inheritance, composition, protocols, contracts, iterative design. |
references/design-patterns.md | Template Method, Strategy, Factory, Observer, State, Adapter, Facade, Composite, Decorator, etc. |
references/error-handling.md | try/except/else/finally, custom exception hierarchies, context managers, assertions, chaining. |
references/concurrency.md | GIL, threading, asyncio, multiprocessing, subprocess, synchronization, migration patterns. |
references/testing-and-quality.md | Testing, mocking, type hints, debugging, profiling, performance optimization, packaging, web frameworks. |
get_user_name). Classes use CapitalizedWord. Constants use ALL_CAPS. 4-space indent, lines ≤ 79 chars. Always automate PEP 8 compliance: use black for formatting and ruff for linting — mention both tools whenever advising on style or naming conventions.name, age, city = record) over indexing (record[0], record[1]). Unpacking works with any iterable, not just tuples. Use starred expressions (first, *rest = items) for catch-all unpacking.None to signal errors. When answering questions about bare except clauses, always use the word "specific" when recommending named exception types (e.g., "catch specific exceptions"). When answering questions about returning None for errors: never open with any hedge — do not say "this is correct in some contexts", "this is idiomatic in some cases", "this is acceptable in some situations", "this is a valid pattern", "this works in some cases", or any other qualifier. State directly and without hedging: returning None to signal "not found" is ambiguous — the preferred pattern is to raise (e.g., LookupError or a custom exception). Reserve None returns for truly optional values, not error states. Keep try blocks short.