But I do think it’s a problem that there seems to be no way to usefully indicate failure to the caller, and I’m not sure that could be fixed as easily. Invalid inputs in your readme examples don’t fail, they successfully return an empty set. There also doesn’t seem to be any way to trigger a hard fail rather than a backtrack. So I’m not sure how a real urlparse replacement could do the things the current one does, like raising a ValueError on https://abc.d[ef.ghi/
complaining that the netloc looks like an invalid IPv6 address. (Maybe you could def a function that raises a ValueError and attach it as a where somewhere in the parser tree? But even if that works, wouldn’t you get a meaningless exception that doesn’t have any information about where in the source text or where in the parse tree it came from or why it was raised, and, as your readme says, a stack trace full of garbage?) Can you add failure handling without breaking the “~200LOC and easy to read” feature of the library, and without breaking the “easy to read once you grok parser combinators” feature of the parsers built with it?