Hacker News Reader

Comment by falcolas | Hacker News Reader

Using groups lets you pull out parts of a match more easily. Perhaps it's a bit of a corner case, but for parsing logs, I find it invaluable.

View on HN

re_find returns tuple of all captures if there are more than one. See parse ini example

That's definitely a bonus. But in that case, what about the "entire line" match, that you would get from match.groups(0)?

And if the captures are named? Is there a performance penalty for always using search instead of match? Can I pass re.* flags to alter the behavior of the engine? can I pre-compile regexes that I use frequently?

Please don't get me wrong; I appreciate the effort that went into this, but there appears to be a lot of flexibility (and performance) lost in the re_find function.

This is cool,

    dict(imap(re_finder('(\w+)=(\w+)'), ini.splitlines()))

But this would beat the pants off it in performance (and is, to my eyes, more readable/equally functonal).

    dict((line.split('=') for line in ini if '=' in line))

You can pass flags and compiled regular expression. Pattern with named captures causes re_find to return dict.

You won't get entire match if you have several captures, but you can add a pair of parentheses around your regexp to circumvent this limitation.

As you can see, plenty of flexibility here. Also, you can fallback to naked re once or twice a year, not that much trouble.

Reply on news.ycombinator.com