Tests for parsers / [regex] pattern matchers in the CPython standard library: https://github.com/python/cpython/blob/master/Lib/test/test_fstring.py https://github.com/python/cpython/blob/master/Lib/test/re_tests.py https://github.com/python/cpython/blob/master/Lib/test/test_re.py https://github.com/python/cpython/blob/master/Lib/test/test_ast.py https://github.com/python/cpython/blob/master/Lib/test/test_unparse.py https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py https://github.com/python/cpython/blob/master/Lib/test/test_tokenize.py https://github.com/python/cpython/blob/master/Lib/test/test_shlex.py https://github.com/python/cpython/blob/master/Lib/test/test_optparse.py https://github.com/python/cpython/blob/master/Lib/test/test_argparse.py Tests for other parsers / pattern matchers written in Python: https://bitbucket.org/mrabarnett/mrab-regex/src/hg/regex_3/test_regex.py https://github.com/r1chardj0n3s/parse/blob/master/test_parse.py https://github.com/pyparsing/pyparsing/blob/master/tests/test_simple_unit.py https://github.com/jszheng/py3antlr4book https://github.com/dateutil/dateutil/blob/master/dateutil/test/test_parser.p... https://github.com/arrow-py/arrow/blob/master/tests/test_parser.py On Sun, Sep 20, 2020, 5:25 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Greg Ewing writes:
On 20/09/20 7:45 am, Christopher Barker wrote:
In [4]: from parse import parse In [5]: parse("{x}{y}{z}", a_string) Out[5]: <Result () {'x': '2', 'y': '3', 'z': '4567'}>
In [6]: parse("{x:d}{y:d}{z:d}", a_string) Out[6]: <Result () {'x': 2345, 'y': 6, 'z': 7}>
So that's interesting -- different level of "greadiness" for strings than integers
Hmmm, that seems really unintuitive. I think a better result would be a parse error -- "I was told to expect three things, but I only found one."
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}? That's perfectly valid *interpreting the 'grammar' as a format string", and therefore might very well be expected. Of course there's probably a rule in parse that {x} is an abbreviation for {x:s}.
Regexps are hard for people to interpret, but they're well-defined and one *can* learn them. If we're going to go beyond regexps in the stdlib (and I'm certainly in favor of that!), 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. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/EYIPHO... Code of Conduct: http://python.org/psf/codeofconduct/