[AMK] > The proposal seems reasonable to me. Thanks. I really hope that this time we can move forward united... > >(Together with a new Unicode regex engine by /F.) > > This is good news! Would it be a from-scratch regex implementation, > or would it be an adaptation of an existing engine? Would it involve > modifications to the existing re module, or a completely new unicodere > module? (If, unlike re.py, it has POSIX longest-match semantics, that > would pretty much settle the question.) It's from scratch, and I believe it's got Perl style, not POSIX style semantics -- per Tim Peters' recommendations. Do we need to open the discussion again? It involves a redone re module (supporting Unicode as well as 8-bit), but its API could be unchanged. /F does the parsing and compilation in Python, only the matching engine is in C -- not sure how that impacts performance, but I imagine with aggressive caching it would be okay. --Guido van Rossum (home page: http://www.python.org/~guido/)
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