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/EYIPHOLUPERDXC6A756HXRK3KQU565O3/
Code of Conduct: http://python.org/psf/codeofconduct/