On 20/09/20 9:25 pm, Stephen J. Turnbull wrote:
Are you sure that shouldn't be "I was told to expect three things, but I found six?" ;-)And why not parse a_string using the "grammar" "{x}{y}{z}" as {'x': 2345, 'y': 6, 'z': 7}?
As a human I tend to expect input formats to be somewhat sensible and have delimiters between runs of letters or digits, so unless told otherwise I would assume 234567 to represent a single number or string. If not, there must be some rule for deciding where to divide it up, in which case that rule should be explicit in the pattern, not implicit in some emergent behaviour of the parser.
let's have a parser that uses a grammar notation that is rarely ambiguous in the way that format strings *usually* are, and when there is ambiguity, demands that the programmer explicitly disambiguate rather than "guessing" in some arbitrary way.
I think we're mostly in agreement. I'm not sure we need yet another pattern language, though. If you have an input language where 234567 represents more than one token, then any way of describing how to parse it will have the same need to disambiguate. The important things are to detect the ambiguity and have a way for the user to resolve it, which I think can be accomplished without inventing a new pattern language. -- Greg _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XSHHFEASVT4Y5A32RHKORNECSDFM4GYX/ Code of Conduct: http://python.org/psf/codeofconduct/
