Hacker News new | past | comments | ask | show | jobs | submit login

I really like how re_find gives you the actual regex match right off the bat, instead of having to go through match_result.groups()!



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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: