René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"agent: prefer dataclasses over named tuples for structured return types","articleBody":"## What happened\n\nA `NamedTuple` was used for `SubprocessResult` — a structured return type holding `stdout` and `stderr` from a subprocess invocation. During review, this was flagged as the wrong choice: a dataclass should have been used instead.\n\n## Root cause\n\nThe agent defaulted to `NamedTuple` when creating a simple two-field container type, likely because named tuples are concise and feel lightweight. However, named tuples inherit tuple semantics (indexing, unpacking, iteration, comparison by position) that are inappropriate for a structured record. These extra behaviours leak implementation details and invite fragile code that depends on field ordering rather than field names.\n\n## Generalised principle\n\nAlways prefer `dataclasses.dataclass` over `typing.NamedTuple` for structured return types and value objects. Named tuples should only be used when tuple semantics (positional access, iteration, structural comparison) are genuinely needed. When the goal is simply to group named fields together, a dataclass is the correct choice — it provides attribute access without the unintended tuple behaviours.\n\n## Resolution\n\nChanged `SubprocessResult` from `NamedTuple` to `@dataclass` in `_subprocess.py`. All existing code accessed fields via `.stdout` and `.stderr` attributes, so no call sites needed updating.\n\n## Follow-up\n\nNone.","author":{"url":"https://github.com/nathanjmcdougall","@type":"Person","name":"nathanjmcdougall"},"datePublished":"2026-04-07T21:24:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1873/usethis-python/issues/1873"}