Wiseman wrote: > I'm kind of disappointed with the re regular expressions module. In > particular, the lack of support for recursion ( (?R) or (?n) ) is a > major drawback to me. There are so many great things that can be > accomplished with regular expressions this way, such as validating a > mathematical expression or parsing a language with nested parens, > quoting or expressions.
-1 on this from me. In the past 10 years as a professional programmer, I've used the wierd extended "regex" features maybe 5 times total, whether it be in Perl or Python. In contrast, I've had to work around the slowness of PCRE-style engines by forking off a grep() or something similar practically every other month. I think it'd be far more valuable for most programmers if Python moved toward dropping the extended semantics so that something one of the efficient regex libraries (linked in a recent thread here on comp.lang.python) could work with, and then added a parsing library to the standard library for more complex jobs. Alternatively, if the additional memory used isn't huge we could consider having more intelligence in the re compiler and having it choose between a smarter PCRE engine or a faster regex engine based on the input. The latter is something I'm playing with a patch for that I hope to get into a useful state for discussion soon. But regexes are one area where speed very often makes the difference between whether they're usable or not, and that's far more often been a limitation for me--and I'd think for most programmers--than any lack in their current Python semantics. So I'd rather see that attacked first. -- http://mail.python.org/mailman/listinfo/python-list
