Mike Coleman <mkc at mathdogs.com> writes: > I suspect that in this case a pure Python implementation might > actually be a lot harder than implementing it as a C patch. This is > because so much of the work is already done in the current re > module; the C patch would probably not be that big. In order to do > it in Python I'd end up reimplementing re.match in Python, which I > wouldn't look forward to. Fairy nuff. I was assuming (on no particular basis - you've obviously looked into this in a lot more detail than me) that you could implement it using re.match - but on reflection, I can see that this would probably not be true. > It's because of this that I'm trying to get as much preliminary > comment as I can. That's reasonable. As I said before, I have a tendency to avoid the re module too much (a perfect recent example was some code I wrote splitting a string on a ":" character, then laboriously trimming each part - I really should have done re.split on \s*:\s*). On that basis, your examples give me a mixed reaction - the results impress me with the ability to get exactly the right information out in a single parse, but the regular expressions needed look utterly unmaintainable. I suppose I'm saying that if I liked re's, I'd love this feature. As it is, it leaves me looking for the same feature but with a better pattern syntax. But your examples reinforce for me that "parse" is a reasonable name for the method. Paul. -- Home computers are being called upon to perform many new functions, including the consumption of homework formerly eaten by the dog -- Doug Larson
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4