[Tim notes that moving to a DFA regexp engine would rule out some future aping of Perl mistakes <wink>] [Barry "The Great Compromiser" Warsaw] > I know zip about the internals of the various regexp package. But as > far as the Python level interface, would it be feasible to support > both as underlying regexp engines underneath re.py? The idea would be > that you'd add an extra flag (re.PERL / re.TCL ? re.DFA / re.NFA ? > re.POSIX / re.USEFUL ? :-) that would select the engine and compiler. > Then all the rest of the magic happens behind the scenes, with > appropriate exceptions thrown if there are syntax mismatches in the > regexp that can't be worked around by preprocessors, etc. > > Or would that be more confusing than yet another different regexp > module? It depends some on what percentage of the Python distribution Guido wants to devote to regexp code <0.6 wink>; the Tcl pkg would be the largest block of code in Modules/, where regexp packages already consume more than anything else. It's a lot of delicate, difficult code. Someone would need to step up and champion each alternative package. I haven't asked Andrew lately, but I'd bet half a buck the thrill of supporting pcre has waned. If there were competing packages, your suggested interface is fine. I just doubt the Python developers will support more than one (Andrew may still be young, but he can't possibly still be naive enough to sign up for two of these nightmares <wink>). i'm-so-old-i-never-signed-up-for-one-ly y'rs - tim
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