paul wrote: > We have three options: >=20 > 1. use the relatively large 4XPath as is >=20 > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) >=20 > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) >=20 > What do you think? if there's a migration path from (2) to (1) (interface-wise, at least), I'd vote for (2). or (2)+(3), if that makes sense. (I know I've promised to look at (1)+(3), but I haven't quite gotten there yet...) </F>
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