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}.
I'm sure there is. but if it were me, I would probably require a format specifier.
Regexps are hard for people to interpret, but they're well-defined and
one *can* learn them.
I'm sure that's truer, but I know I haven't yet ;-). But it's only been 30 years or so ....
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,
That was my point originally. but in fact, we already DO have regex. So what is the goal of a new syntax? It's certainly not more power or flexibility.
So I think I'm actually coming around -- it is pretty nice to be able to use a parsing language that's familiar and simple, even if it doesn't give you full flexibility.
-CHB
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython