> It won't be as elegant as having access to a combinator-parser, but all of the AoC problems aren't parsing problems.

Yeah, this is essentially it for me. While it might not be a 'type-safe and correct regarding error handling' approach with Python, part of the interest of the AoC puzzles is the ability to approach them as 'almost pure' programs - no files except for puzzle input and output, no awkward areas like date time handling (usually), absolutely zero frameworks required.

> you can just wing things and work with a mess of dictionaries and lists.

Checks previous years type-hinted solutions with map[tuple[int, int], list[int]]

Yeah...

> but all of the AoC problems aren't parsing problems.

I'd say for the first ten years at least the first ten-ish days are 90% parsing and 10% solving ;) But yes, I agree, and maybe I'm worrying over a few extra visible err's in the code that I shouldn't be.

> if you just want to LLM your way through

Totally fair point if I constrain LLM usage to input handling and the things that I already know that I know how to do but don't want to type, although I've always quite liked being able to treat each day as an independent problem with no bootstrapping of any code, no 'custom AoC library', and just the minimal program required to solve the problem.