Paul Moore writes:
However, I do like the idea of having a better parser library in the stdlib. But it's pretty easy to write such a thing and publish it on PyPI,
It's not easy to write a good one. I've tried in two languages (Python and Lisp). I'm not saying I'm competent, so that's a faint damn.
so the lack of an obvious "best in class" answer for this problem suggests that people would be less likely to use such a feature than we're assuming.
To me it suggests that it's hard to come up with a UI that's clearly better than regexp.
Do people choose regexes over these because re is in the stdlib?
Almost certainly, to some extent.
Or is there an attraction to regexes that makes people prefer them in spite of the complexity/maintainability issues?
I think that a lot of it is that people are extremely comfortable with globbing, and re at first glance looks like globbing on steroids with no downside. On the other hand, parsing is "known" (note scare quotes) to be hard, people *hate* "grammar", and unlike grep and sed which are simple enough to be usable at the command line, not only isn't lex embedded in yacc, but both really need to be saved in files and compiled, then run, to be tested. It just feels really heavy compared to regexp. I think that if experienced people used parsers more they would get general uptake. But people seem to think that parsers are for experts, more so than regexp. That's why I chose a simple list-with-annotations rather than something like Chris's idea which in Python looks like magic. "If we could just make it *this* simple ..." Steve