selectolax VS lxml

https://github.com/rushter/selectolax#simple-benchmark )

(Apache Nutch is a Java-based web crawler which supports e.g. CommonCrawl (which backs various foundational LLMs)) https://en.wikipedia.org/wiki/Apache_Nutch#Search_engines_bu... . But extruct extracts more types of metadata and data than Nutch AFAIU: https://github.com/scrapinghub/extruct )

datasette-graphql adds a GraphQL HTTP API to a SQLite database:

selectolax

Lazyweb link: https://github.com/rushter/selectolax

although I don't follow the need to have what appears to be two completely separate HTML parsing C libraries as dependencies; seeing this in the readme for Modest gives me the shivers because lxml has _seen some shit_

> Modest is a fast HTML renderer implemented as a pure C99 library with no outside dependencies.

although its other dep seems much more cognizant about the HTML5 standard, for whatever that's worth: https://github.com/lexbor/lexbor#lexbor

---

> It looks like the author of the article just googled some libraries for each language and didn't research the topic

Heh, oh, new to the Internet, are you? :-D

lxml

Parsel is a library build to extract data from XML/HTML documents with XPath and CSS selectors support, and could be combined with regular expressions. It's usees lxml parser under the hood by default.

So, now that I no longer work in that industry, and I had some free time, I created a lazy parsing package using lxml instead of the xml parser in the standard library, which can help people who want to have a python only parsing solution.

I got curious about this now so I did some tests on my own, and it appears that the XML parser implementation in Python does indeed strip all newline characters from attributes. Whether this is according to XML standard I do not know; I also briefly tried an alternative XML implementation for Python and it behaves the same, so I would assume that this is standard behavior, but I'm not knowledgable enough about XML to say for certain.

I use lxml for the XML parsing and pyodbc as the ODBC library. We have a small team so I just keep it as simple as possible: 1. A cursor yields the XML documents from a SQL query as a stream 2. A generator function parses the XML document and yields the rows (you could parallelize this step) 3. Stream each of the resulting rows to a single CSV file 4. Scoop up the resulting CSV file into the target database (usually with the DB engine's loader; bulk insert isn't so fast over ODBC) It ends up being a straight forward, low-overhead approach.

Generally, I'm already using Python to glue together things like OpenCV or libxml, which do the heavy-lifting, and taking advantage of how things like Qt's QImage release Python's Global Interpreter Lock, allowing me to load and process images on a background thread, so the Python code itself is usually already I/O-bound, but yes. If the Python code would become a bottleneck, it helps with that too.

lxml is an XML parser however, it also supports HTML parsing. It's blazing fast and supports XPath. I think it isn't as beginner friendly to use, though it has detailed documentation. It works less well with heavily broken HTML documents and the encoding detection isn't as good as the one of BS4.

According to lxml benchmarking docs, Python’s built in xml parser wouldn’t behave that bad either: https://github.com/lxml/lxml/blob/master/doc/performance.txt