|
| 1 | +# Python Checklist Test Programs |
| 2 | + |
| 3 | +This suite mirrors the `ruby_checklist` sample by collecting small, |
| 4 | +targeted probes that exercise diverse areas of the Python language and |
| 5 | +standard library. The code is intentionally verbose and heavily |
| 6 | +commented so that engineers working across multiple languages can |
| 7 | +quickly understand what a probe demonstrates and why it matters. |
| 8 | + |
| 9 | +## Goals |
| 10 | + |
| 11 | +- Capture representative call stacks for critical Python features so the |
| 12 | + debugger and tracer integrations can be validated. |
| 13 | +- Provide ready-made snippets that illustrate specific language |
| 14 | + behaviors, pitfalls, and idioms for reference during development. |
| 15 | +- Keep each probe independent and side-effect light so they can run in |
| 16 | + isolation without hidden dependencies. |
| 17 | + |
| 18 | +## Organization |
| 19 | + |
| 20 | +- Minimum Python version: **3.11**. This allows us to cover structural |
| 21 | + pattern matching, `except*` for exception groups, and other |
| 22 | + post-3.10 features without fallbacks. |
| 23 | +- Each feature cluster lives in its own module (for example, |
| 24 | + `basics.py`, `functions_exceptions.py`, …). Modules should export |
| 25 | + numbered `demo_*` functions that focus on a single behavior. |
| 26 | +- A top-level `run_all()` function inside each module executes its demos |
| 27 | + sequentially, printing numbered lines so missed events are easy to |
| 28 | + spot in traces. |
| 29 | +- Inline comments and docstrings must explain **what** the snippet does, |
| 30 | + **why** someone would use it, and any common gotchas. |
| 31 | +- Helpers that spin up threads or processes must protect their entry |
| 32 | + points with `if __name__ == "__main__":` to stay portable across |
| 33 | + platforms (especially Windows). |
| 34 | + |
| 35 | +## Feature Coverage |
| 36 | + |
| 37 | +| Area | Modules / Demos | Notes | |
| 38 | +| --- | --- | --- | |
| 39 | +| Literals, operators, control flow | `basics.run_all()` | Covers literals, slicing, unpacking, match/case, loop `else`. | |
| 40 | +| Functions, decorators, exceptions | `functions_exceptions.run_all()` | Demonstrates call signatures, mutable defaults, closures, decorator stacking, caching, chained exceptions, `ExceptionGroup`. | |
| 41 | +| Context managers & iterators | `contexts_iterators.run_all()` | Custom `__enter__/__exit__`, `contextlib`, iterator protocol, generators with `send`/`throw`/`close`. | |
| 42 | +| Async & concurrency | `async_concurrency.run_all()` | Async context/iter, `create_task`, contextvars, threading/TLS, `ThreadPoolExecutor`, guarded multiprocessing. | |
| 43 | +| Data model & classes | `data_model.run_all()` | `__repr__`, formatting, rich ops, properties with `__slots__`, attribute hooks, descriptors, subclass hooks, metaclass lifecycle. | |
| 44 | +| Collections & dataclasses | `collections_dataclasses.run_all()` | Dataclasses with slots/order, enums and flags, namedtuple/deque/defaultdict/Counter, mapping proxy, pattern matching with `__match_args__`. | |
| 45 | +| System utilities | `system_utils.run_all()` | `subprocess.run` with env overrides, tz-aware datetime math, `Decimal`/`Fraction`, deterministic random, regex capture groups. | |
| 46 | +| Introspection & dynamic code | `introspection.run_all()` | `inspect.signature`, dynamic attributes, globals/locals snapshots, `eval`/`exec`/`compile`, AST parse/dump (with security notes in comments). | |
| 47 | +| Import system | `imports_demo.run_all()` | Runtime module creation via `types.ModuleType`, adjusting `sys.path`, `importlib.import_module`, `__all__`, module caching notes. | |
| 48 | +| Logging, warnings, GC, typing | `advanced_runtime.run_all()` | Scoped logging config, forced warnings, GC cycle collection with weakrefs/finalizers, runtime protocol checks, generics. | |
| 49 | +| Miscellaneous constructs | `miscellaneous.run_all()` | `iter(callable, sentinel)`, `del`, custom mapping protocol, context manager without suppression. | |
| 50 | + |
| 51 | +> **Planned additions:** Remaining entries from the original checklist |
| 52 | +> (I/O & serialization, subprocess variants, JSON/pickle, etc.) can be |
| 53 | +> layered in by following the same pattern—add `<topic>.py`, expose |
| 54 | +> `run_all()`, then register it in `__main__.py`. |
| 55 | +
|
| 56 | +## Running The Suite |
| 57 | + |
| 58 | +Once all modules are implemented, you will be able to run the entire |
| 59 | +checklist from the project root: |
| 60 | + |
| 61 | +```bash |
| 62 | +python -m test-programs.python_checklist |
| 63 | +``` |
| 64 | + |
| 65 | +During early development, it is fine to run individual modules directly |
| 66 | +with `python test-programs/python_checklist/<module>.py` to iterate on a |
| 67 | +specific feature cluster. |
| 68 | + |
| 69 | +## Contribution Guidelines |
| 70 | + |
| 71 | +- Follow the numbering scheme diligently so console output gaps surface |
| 72 | + immediately. |
| 73 | +- Prefer deterministic behavior (avoid randomness unless the purpose is |
| 74 | + to exercise the random module). |
| 75 | +- Clean up temporary files, subprocesses, and other resources within the |
| 76 | + probe itself. Each demo should leave the environment in the same state |
| 77 | + it found it. |
| 78 | +- If a snippet showcases risky behavior (e.g., `eval`), highlight the |
| 79 | + security implications in comments. |
| 80 | + |
| 81 | +This structure keeps the checklist maintainable and allows future |
| 82 | +contributors to plug in additional probes without surprising teammates. |
0 commit comments