हर “सबसे तेज़ Python HTML parser” वाली पोस्ट आखिर में selectolax का नाम ले ही लेती है, और लगभग हर लेख कहानी को “BeautifulSoup से कहीं तेज़” कहकर खत्म कर देता है। वह बात सही है। लेकिन जो हिस्सा अक्सर अधूरा रह जाता है, वह तब सामने आता है जब selectolax की तुलना lxml से की जाए — क्योंकि वहाँ “सबसे तेज़” के साथ एक छोटा-सा सवालिया निशान जुड़ जाता है।
इसलिए मैंने इसे ठीक से बेंचमार्क किया: selectolax (इसके दोनों बैकएंड्स के साथ) बनाम lxml, BeautifulSoup को html.parser और lxml दोनों के साथ, और parsel — पाँच अलग-अलग पेज साइज़ पर, 1 KB से 10 MB तक, और हर माप तीन अलग-अलग प्रोसेस रन का median लेकर लिया गया। selectolax ने BeautifulSoup को बहुत बड़े अंतर से पीछे छोड़ा और raw lxml के बराबर आया — लेकिन pure parsing के चरण में lxml से पीछे रह गया। नीचे दिए गए सारे आँकड़े provisional हैं और सिर्फ़ एक मशीन से लिए गए हैं (macOS arm64, Python 3.14.2); scripts committed हैं, इसलिए मेरे शब्दों को उद्धृत करने से पहले इन्हें अपनी मशीन पर ज़रूर चलाएँ।
selectolax असल में है क्या (और क्या नहीं)
selectolax एक Python binding है दो C engines — Modest और Lexbor — के लिए, जो HTML5 को parse करते हैं और CSS selectors से query करने देते हैं। यह crawler नहीं है, browser नहीं है, और button-click वाले अर्थ में “scraper” भी नहीं है। इसे आप तब इस्तेमाल करते हैं जब HTML पहले ही fetch हो चुका हो और आपके पास सिर्फ़ उसका blob हो। maintainer का अपना one-liner है: “A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines.”
इसके दो बैकएंड हैं, और उनके बीच का फर्क docs से ज़्यादा अहम है:
LexborHTMLParser(Lexbor engine) — वही जिसे README 2024 के हिसाब से उपयोग करने को कहती है।HTMLParser(Modest engine) — मूल वाला, जिसका underlying C library, उसी README के अनुसार, “अब maintained नहीं है।”
Speed पर जाने से पहले कुछ तथ्य जान लेना उपयोगी है। repo snapshot (2026-07-10) के अनुसार selectolax के 1,653 stars हैं और latest release v0.4.10 (May 2026) है; PyPI इसे Python >=3.9,<3.15 तक सीमित करता है। install इस पूरे review का सबसे कम नाटकीय हिस्सा है: pip install selectolax ने 2.3 MB का prebuilt cp314 wheel तुरंत डाउनलोड किया और Python 3.14 पर बिना किसी झंझट के चल गया — browser download नहीं, doctor step नहीं, compilation नहीं। यही एक pure parser की शांत ताकत है, browser-backed tool के मुकाबले। बस import होता है और चल पड़ता है।
एक licensing बारीकी अभी नोट कर लेना बेहतर है: Python binding MIT है, लेकिन wheel में bundled engines के अपने licenses हैं — Modest LGPL-2.1 है, Lexbor Apache-2.0 है। इसलिए “selectolax MIT है” Python code के लिए सही है, लेकिन उस binary के लिए पूरा सच नहीं, जिसे आप ship करते हैं। अगर आपकी legal team redistributed components पर ध्यान देती है, तो यह अंतर ज़रूर बताना चाहिए।
स्पीड का सवाल, असली आँकड़ों के साथ
मैंने यह task timed किया: HTML string को parse करना, हर <h3 class="title"> का text निकालना, और हर <a> का href निकालना। latency milliseconds में मापी गई; हर value तीन अलग-अलग process runs के median के रूप में ली गई। C-backed parsers के लिए ज़्यादातर sizes पर cross-run spread लगभग 5% से कम रहा। timing से पहले हर parser के output को content hash में बदला गया, ताकि अगर कोई parser चुपचाप कम काम करे तो पकड़ में आ जाए और exclude हो सके — इन pages पर सभी छह parsers हर size पर match हुए, इसलिए यह वास्तव में apples-to-apples तुलना है। पूरा data committed bench_parse.json में मौजूद है।
| Page | selectolax (Lexbor) | selectolax (Modest) | lxml | parsel | BS (lxml) | BS (html.parser) |
|---|---|---|---|---|---|---|
| 1 KB | 0.027 | 0.029 | 0.036 | 0.044 | 0.281 | 0.323 |
| 10 KB | 0.160 | 0.171 | 0.166 | 0.228 | 1.705 | 2.049 |
| 100 KB | 1.464 | 1.565 | 1.423 | 2.020 | 16.5 | 20.6 |
| 1 MB | 14.901 | 16.9 | 14.177 | 20.9 | 181.9 | 232.6 |
| 10 MB | 159.9 | 247.9 | 172.9 | 231.9 | 2261.6 | 2788.7 |
BeautifulSoup के मुकाबले: लगभग 12-17x, और आम धारणा इसे कम आँकती है
इन आँकड़ों को ratio में बदलें तो selectolax-Lexbor 1 KB पेज पर BeautifulSoup(html.parser) से लगभग 12x तेज़ निकलता है, और 10 MB पर लगभग 17x तक पहुँच जाता है। उसी range में यह BeautifulSoup(lxml) से लगभग 10-14x तेज़ है। ऑनलाइन जो आँकड़ा घूमता है — “selectolax BeautifulSoup से लगभग 4-5x तेज़ है” — वह html.parser के मुक़ाबले कम पड़ता है और लगभग सिर्फ़ lxml-backed BeautifulSoup के सामने करीब लगता है। असली multiple इस पर निर्भर करता है कि आप कौन-सा BeautifulSoup इस्तेमाल कर रहे हैं और हर पेज पर कितना extraction कर रहे हैं।
यह README के अपने benchmark से भी मेल खाता है, जहाँ 25.5x का edge दिखता है BeautifulSoup(html.parser) के मुकाबले। दोनों आँकड़े गलत नहीं हैं। README का task (छोटे homepages से title, links, scripts, और meta निकालना) छोटे pages पर कम extraction करता है, इसलिए BeautifulSoup का per-parse overhead ज़्यादा भारी दिखता है। range के हिसाब से देखें तो: real-world parse-and-extract काम में selectolax आम तौर पर BeautifulSoup से 10-15x तेज़ है, छोटे pages और हल्के extraction पर यह अंतर और बढ़ जाता है।
अगर आपका मौजूदा bottleneck BeautifulSoup code का कोई बड़ा pile है जो pages को खा रहा है, तो यह वही migration है जो अपने खर्चे वसूल कर लेती है। यह दावा विवादित नहीं है। अगला हिस्सा थोड़ा और दिलचस्प है।
lxml के मुकाबले: लगभग बराबरी — और pure parsing में lxml वही हिस्सा जीतता है जिसे अक्सर अलग नहीं किया जाता
100 KB और 1 MB वाली rows को फिर से देखें। Lexbor और lxml लगभग 5% के भीतर हैं, उनके per-run bands overlap करते हैं, और मेरी methodology के हिसाब से यह tie है — कोई clear winner नहीं, “तेज़” का ठोस दावा नहीं। जहाँ selectolax सचमुच आगे निकलता है, वह 10 MB पेज है (159.9 ms बनाम 172.9 ms, यानी 8.1% का gap, और intervals overlap नहीं करते)। इसलिए full task पर selectolax lxml के बराबर आता है और केवल बहुत बड़े documents पर उससे आगे निकलता है।
फिर मैंने tree construction को CSS querying से अलग किया, और नतीजा उस दिशा में पलट गया जिसे ज़्यादातर write-ups मिस कर देते हैं। सिर्फ़ parsing, बिना किसी query के, इस machine पर lxml लगातार selectolax-Lexbor से लगभग 33-34% तेज़ रहा — 10 MB पेज पर 77.9 ms बनाम 116.6 ms। पूरे task में दोनों फिर भी काफ़ी करीब आ जाते हैं, और मेरा working hypothesis (जिसे मैंने attribution experiment से साबित नहीं किया) यह है कि इन pages पर CSS query total time का छोटा हिस्सा है, इसलिए lxml की parsing lead कुल समय में दब जाती है और दोनों बराबरी पर आ जाते हैं।
यह इस पूरे review का सबसे आसानी से चुनौती दिया जाने वाला दावा है, और मैं इसकी वजह खुलकर बता देना चाहता हूँ। यह आम धारणा के उलट है, और जो एक published benchmark मुझे मिला जो parse-only को अलग करता है — aows.jpt.sh — वह उल्टा परिणाम देता है, यानी selectolax को लगभग 4x तेज़ बताता है। इसलिए मैंने इसे सुरक्षित सीमा में रखा है: यह result single-platform है (macOS arm64, Python 3.14, prebuilt cp314 wheels — Linux x86_64 या source build की जाँच नहीं हुई), इसे चार page sizes पर cross-check किया गया और हर बार यही result मिला, और दो अलग-अलग lxml APIs से भी दोबारा verify किया गया ताकि API artifact की संभावना हटाई जा सके। दोनों lxml APIs हर size पर selectolax-Lexbor से आगे रहे। मैं “lxml parse में तेज़ है” को अंतिम सच की तरह नहीं पेश कर रहा — मैं इसे वही बता रहा हूँ जो मेरी bench ने निकाला, script के साथ, published numbers के उलट। इसे अपनी मशीन पर चलाइए।
एक और slice: flat page पर 100,000 <a> को query करने में lxml और selectolax-Modest बराबरी पर रहे (33.30 ms बनाम 34.19 ms, bands overlap करते हैं), जबकि selectolax-Lexbor दोनों से लगभग 15% पीछे रहा। तीनों C engines में समान बात यह है कि bulk selection में ये parsel या BeautifulSoup से 5-7x तेज़ हैं, क्योंकि उन libraries का Python-object-per-node मॉडल असली bottleneck है। इसलिए “bulk CSS selection में selectolax सबसे तेज़ है” भी सही नहीं बैठता — Modest केवल lxml के बराबर है, और Lexbor उससे पीछे है।
जिस निष्कर्ष पर मैं सच में खड़ा रहूँगा, वह यह है: lxml पर selectolax की बढ़त broad, full-task speed में नहीं है। यह केवल सबसे बड़े page पर जीतता है। इसकी असली दलील दूसरी चीज़ों पर टिकी है — API ergonomics, खराब input पर व्यवहार, और modern CSS — और वही इस review के बाकी हिस्से का केंद्र है।
Memory और cold start: profiler नहीं, RSS के आधार पर rank करें
Memory वह जगह है जहाँ मुझे अपनी ही पुरानी numbers सुधारनी पड़ीं, और यही इस correction का मक़सद है। 10 MB page पर tracemalloc बंद रखकर RSS delta के रूप में मापने पर, BeautifulSoup selectolax या lxml की तुलना में लगभग 1.5-1.8x ज़्यादा memory लेता है — range 1.51x (BS-lxml, 218.4 MB बनाम Lexbor के 144.6 MB) से लेकर top end पर 1.75x तक जाती है। selectolax और lxml lean tier में साथ हैं; RSS के हिसाब से lxml सबसे हल्का है।
मेरे पिछले pass में “~3x” लिखा था, और वह संख्या एक सीख देने वाली वजह से गलत थी: वह tracemalloc चालू रखकर मापी गई थी, और tracemalloc का per-allocation bookkeeping सबसे ज़्यादा allocations वाले parser की apparent RSS को लगभग दोगुना दिखा देता है। इसलिए parser memory benchmark करने वालों के लिए एक साफ़ सलाह: profiler बंद रखकर RSS के आधार पर rank करें। tracemalloc peak के आधार पर parsers को rank करना खासकर C-backed parsers के बीच order बिगाड़ देता है — इससे selectolax-Lexbor, वास्तविक RSS में Modest से बहुत अलग न होने पर भी, भारी दिखा। यहाँ असल में सबसे भारी BeautifulSoup है; बस वह 3x के उस अंतर से भारी नहीं है जो दूषित instrument ने दिखाया था।
Cold start छोटा लेकिन वास्तविक है: selectolax लगभग 14 ms में import हो जाता है, जो lxml के करीब है और bs4 या parsel से लगभग 2.3x तेज़ है। अगर आप CLI tool या serverless function ship कर रहे हैं, जहाँ import time हर invocation का हिस्सा है, तो यह अंतर मायने रखता है।
CSS selector coverage: मजबूत, लेकिन कुछ असली खामियों के साथ
CSS coverage के लिए 41-case matrix चलाया गया, हर selector को एक ऐसे fixture पर परखा गया जिसके सही answers पहले से ज्ञात थे, और साथ में Lexbor engine को तोड़ने के लिए एक जानबूझकर fault-finding pass भी किया गया। हर case अपने अलग subprocess में चला, और यह ज़रूरी भी था — इनमें से एक पूरा interpreter crash कर देता है। नतीजे:
| Engine | PASS | WRONG | UNSUPPORTED | PROCESS_ABORT |
|---|---|---|---|---|
| soupsieve | 41 | 0 | 0 | 0 |
| selectolax Lexbor | 39 | 0 | 2 | 0 |
| lxml (cssselect) | 37 | 1 | 3 | 0 |
| parsel (cssselect) | 37 | 1 | 3 | 0 |
| selectolax Modest | 35 | 3 | 2 | 1 |
hostile selectors को mix में डालने पर Lexbor अकेला winner नहीं रह जाता — winner soupsieve है, जो 41/41 पर साफ़ खड़ा है, जबकि Lexbor 39/41 पर है। Lexbor की दो misses हैं :lang(en) और :dir(rtl), जिन्हें वह parse error के साथ reject करता है। बाकी सब पर यह बिल्कुल सही है, जिसमें :has(), :is(), :where(), और case-insensitive attributes शामिल हैं।
जहाँ Lexbor खास चमकता है, वह cssselect stack के सामने है। README का headline selector — div > :nth-child(2n+1):not(:has(a)) — दोनों selectolax engines और soupsieve में सही result देता है, लेकिन lxml और parsel में गलत set लौटाता है, और कोई error भी नहीं देता। जो scraper वही selector Scrapy या parsel में कॉपी कर देता है, उसे silently गलत result मिलेंगे। framing को साफ़ रखें: cssselect ने :has() को version 1.2.0 (2022) से parse करना शुरू कर दिया था, और मैंने 1.4.0 test किया, इसलिए यह “unsupported” नहीं बल्कि “supported but compound को गलत evaluate करता है” वाला मामला है। इस particular compound पर silent-wrong-set व्यवहार cssselect tracker में दर्ज :has() limits जैसा नहीं है, जहाँ error raise होता है। Lexbor case-insensitive attribute flag [data-role="LEAD" i] को भी संभाल लेता है, जिसे cssselect सीधे reject कर देता है।
फिर भी दो gaps migrations तय करते हैं। selectolax में XPath बिल्कुल नहीं है — कोई भी backend xpath() expose नहीं करता — और ::text / ::attr() pseudo-elements भी नहीं हैं, क्योंकि ये parsel/Scrapy extension हैं, असली CSS नहीं। अगर आपके मौजूदा scrapers XPath पर टिके हैं, तो यही सबसे बड़ी दीवार होगी; आपको selectors rewrite करने पड़ेंगे, library सिर्फ़ replace नहीं होगी। दूसरी ओर, Lexbor :lexbor-contains("text" i) pseudo-class देता है, जो case-insensitive text matching के लिए है और जिसे न lxml, न parsel, न standard CSS offer करते हैं; और यह documentation के अनुसार काम भी करता है।
खराब HTML पर मजबूती, जहाँ selectolax अपनी कीमत वसूलता है
असल scraping का मतलब है parser को कचरा खिलाना और उम्मीद करना कि वह टूटे नहीं। मैंने 18 adversarial inputs चलाए, और यही वह category है जहाँ lxml के मुकाबले selectolax की दलील सबसे मज़बूत निकलती है।
lxml.html.fromstring को empty string या सिर्फ़ whitespace दें, तो वह ParserError("Document is empty") फेंक देता है। दोनों selectolax engines इसके बजाय एक valid, empty tree लौटा देते हैं। अगर आपका scraper URLs की एक सूची पर loop कर रहा है और कुछ responses blank आ जाते हैं, तो इसका मतलब है कि आपको हर जगह एक और try/except लिखने की ज़रूरत नहीं पड़ेगी। selectolax ने 100,000 elements को बिना stack overflow के भी संभाल लिया।
Deep nesting ने सबसे साफ़ फर्क दिखाया। 1,000 और 5,000 स्तर के nested <div> पर, lxml चुपचाप सबसे गहरी content छोड़ देता है, जबकि selectolax उसे बनाए रखता है। libxml2 लगभग 256 levels पर parse depth cap कर देता है और tree को बिना error truncate कर देता है, इसलिए सबसे गहरी text बस unreachable रह जाती है। दोनों selectolax engines पूरा tree लौटाते हैं। यह <template> वाली trap का उल्टा चेहरा है, जिस पर अभी आएँगे: वहाँ Lexbor content गिरा देता है, बाकी उसे रख लेते हैं; यहाँ lxml content गिरा देता है, selectolax उसे बचा लेता है।
हर cell जीत नहीं थी। Modest backend :dir() से टकराते ही पूरे Python interpreter को SIGABRT के साथ abort कर देता है — यह ऐसी exception नहीं है जिसे आप पकड़ सकें, यह एक hard process kill है। legacy backend पर अभी भी रहने वालों के लिए यह real robustness caveat है, और यही वह तरह की चीज़ है जो तब तक नहीं दिखती जब तक 3 बजे रात production job गिर न जाए।
दो silent-data-loss traps, जिन्हें ship करने से पहले जानना ज़रूरी है
इनमें से कोई भी नया discovery नहीं है — दोनों upstream पर documented हैं — लेकिन दोनों real data silently खो देते हैं, और README में यह बात उतनी ज़ोर से नहीं कही गई है।
Lexbor <template> के अंदर के <a> छोड़ देता है
मैंने जिस live MDN page को test किया, उस पर selectolax-Lexbor को 497 links मिले, जबकि lxml, BeautifulSoup के दोनों backends, और यहाँ तक कि selectolax का अपना Modest backend भी 508 links तक पहुँचा। जो 11 links गायब थे, वे language-switcher और discussions link थे, जो <template> elements के अंदर थे (page Lit web components इस्तेमाल करती है)।
इसका मूल कारण वैध है: HTML5 spec के अनुसार <template> content normal DOM में नहीं, बल्कि एक अलग inert fragment में parse होता है, और Lexbor इसे कड़ाई से follow करता है — tree.css("a") template content में नहीं उतरता। lxml, BeautifulSoup के दोनों backends, और Modest template content को main tree में flatten कर देते हैं, इसलिए वे links पकड़ लेते हैं। यह एक documented open issue है (selectolax#146, और engine root cause lexbor#170 पर है), और दोनों interpretations defendable हैं — Lexbor संभवतः spec के ज़्यादा करीब है। लेकिन recommended backend पर काम करने वाला developer बिना किसी error के वही data मिस कर सकता है। उल्टा सच भी कहना चाहिए: बाकी parsers inert template content दिखा देते हैं, जिसे browser कभी render नहीं करता, इसलिए वे ऐसा phantom data भी दे सकते हैं जो user को दिखता ही नहीं। इस खास page के लिए reliable escape hatch Modest backend है, या कोई दूसरी library।
Non-UTF-8 bytes .text() को चुपचाप corrupt कर देते हैं
अगर आप selectolax को ऐसे bytes दें जो valid UTF-8 नहीं हैं, तो parsing सफल हो जाएगी — corruption बाद में सामने आती है, और यह clean crash से भी बुरी है। "<p>café éè</p>".encode("latin-1") पर Lexbor की .text() replacement characters लौटाती है, Modest की .text() offending bytes को silently हटा देती है, और दोनों engines केवल तब UnicodeDecodeError देते हैं जब आप .html को छूते हैं। binding read-back के समय strict UTF-8 decode करती है, parse के समय नहीं। यह selectolax issue से संबंधित है, जहाँ encode/decode strictness की समस्या दर्ज है।
समाधान एक लाइन का है और आदत में शामिल हो जाना चाहिए: bytes को पहले खुद decode करें — LexborHTMLParser(resp.content.decode("latin-1")) — और दोनों engines 'café éè' सही लौटाएँगे। व्यवहार में selectolax को हमेशा str दें, raw non-UTF-8 bytes नहीं। README यह बात साफ़ नहीं कहती।
Production से जुड़े पहलू (single-observation हैं, इसलिए इन्हें direction समझें)
अगले नतीजे मैंने सिर्फ़ एक बार मापे हैं, तीन runs के औसत से नहीं, इसलिए इन्हें पक्के आँकड़े नहीं बल्कि signals की तरह पढ़ें।
Thread scaling सबसे दिलचस्प है। 1 MB page को चार threads में 48 बार parse करने पर, selectolax ने लगभग 3.5-3.9x wall-clock speedup दिखाया — यह एक ऐसी library की signature है जो C parsing के दौरान GIL छोड़ देती है — जबकि BeautifulSoup(lxml) threaded mode में कई गुना धीमा हो गया, जो इस बात का संकेत है कि काम GIL पर serialize हो रहा है। lxml बीच में रहा और निष्कर्ष साफ़ नहीं निकला। Python के free-threading युग की ओर बढ़ने के साथ, selectolax का ऐसा parsing जो threads में parallelize हो जाता है, जहाँ BeautifulSoup नहीं हो पाता, एक असली—भले provisional—फ़ायदा है। यह एक page size पर एक thread count के साथ लिया गया परिणाम है, और इसका mechanism hypothesis है, C code instrument करके proven चीज़ नहीं।
Leaks के मामले में: 1 MB पर 2,000 parse-extract-drop iterations के बाद, तीनों parsers में किसी ने भी leak जैसी linear RSS climb नहीं दिखाई — हर एक एक bounded working-set band में स्थिर हो गया। मैं इस परिणाम पर खास तौर पर भरोसा करता हूँ क्योंकि मैंने उसी instrument से एक known-leak calibration subject भी चलाया, और वह जानबूझकर +198 MB तक चढ़ा, जिससे साबित हुआ कि instrument leak देख सकता था और parsers में कोई leak नहीं मिला। और tree के scope से बाहर होने के बाद भी node handle usable रहा, कोई segfault नहीं आया। यह भी single-observation है; कोई लंबा soak test नहीं।
selectolax कहाँ फिट होता है — और कहाँ handoff करता है
ऊपर की सारी बात एक ही काम के बारे में है: आपके पास जो HTML पहले से है, उसे तेज़ी से structured data में बदलना। selectolax इस काम में बहुत अच्छा है। लेकिन यह intentionally page fetch नहीं करता, JavaScript render नहीं करता, proxy rotate नहीं करता, CAPTCHAs solve नहीं करता, और यह भी नहीं तय करता कि आपको कौन-से elements चाहिए। यह सब अभी भी आपका code है। selectolax parsing layer है, और इससे ज़्यादा होने का ढोंग नहीं करता।
यहीं वह सीमा आती है जहाँ managed extraction service parser के ऊपर बैठता है, parser को replace नहीं करता। अगर आप खुद fetch-render-anti-bot-extract stack बनाना और संभालना नहीं चाहते, तो Thunderbit इसे API, MCP server, और CLI के रूप में देता है — POST /distill किसी page को clean Markdown में बदल देता है और POST /extract schema-matched structured JSON लौटाता है, जबकि JS rendering और anti-bot आपके लिए संभाल लिए जाते हैं। यह problem की अलग layer है: जब आपके पास HTML पहले से हो और आप अपनी control में raw parsing speed चाहते हों, तब selectolax चुनिए; और जब fetching तथा extraction संभाली हुई चाहिए और बस structured data वापस चाहिए, तब Thunderbit के API, MCP server, या CLI जैसे विकल्प देखें। यह swap नहीं है — उसी stack की अलग ऊँचाई है।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ
फायदे, नुकसान, और असल में किसे इसे इस्तेमाल करना चाहिए
जहाँ selectolax जीतता है:
- वास्तविक parse-and-extract काम में BeautifulSoup से लगभग 12-17x तेज़, और page-size की तीन orders of magnitude range में स्थिर।
- कम memory use (lxml tier, BeautifulSoup से लगभग 1.5-1.8x हल्का) और लगभग 14 ms import time।
- उन inputs पर graceful जो lxml को तोड़ देते हैं — empty, whitespace, और बेहद गहरी nesting।
- आधुनिक CSS सपोर्ट:
:has(),:is(),:where(), case-insensitive attributes, और Lexbor-only:lexbor-contains(). - None-safe DOM read/write: missing elements
Noneया[]लौटाते हैं, throw नहीं करते, और tree को mutate तथा re-serialize भी किया जा सकता है। - सक्रिय maintenance (v0.4.10, mid-2026) और बेहद आसान install।
जहाँ यह नहीं जीतता:
- lxml से broadly तेज़ नहीं — full task पर बराबरी, और pure-parse step में मेरी bench पर पीछे।
- XPath नहीं, और
::text/::attr()भी नहीं — XPath-based scrapers के लिए migration की बड़ी दीवार। - दो silent-data-loss traps: Lexbor पर
<template>content, और.text()के ज़रिए non-UTF-8 bytes। - Modest backend legacy है और
:dir()पर SIGABRT कर सकता है। - यहाँ दिए गए सारे आँकड़े single-platform (macOS arm64, Python 3.14) और provisional हैं।
तो क्या आपको selectolax इस्तेमाल करना चाहिए? हाँ, अगर आप lxml-class parsing speed के साथ ज़्यादा friendly, None-safe API और empty/malformed input पर बेहतर व्यवहार चाहते हैं — और आप CSS-only territory में रहने के लिए तैयार हैं। अगर आपका codebase XPath पर बना है, तो rewrite का खर्चा वास्तविक है और उसे ईमानदारी से तौलना चाहिए। और अगर आप “सबसे तेज़ parser” खोज रहे हैं, तो इस bench से सही जवाब यह है कि selectolax और lxml इतने करीब हैं कि निर्णायक factor ergonomics और robustness हैं, raw speed नहीं। वैसे भी tool चुनने की यह एक बेहतर वजह है।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ Get Started Free
FAQs
क्या selectolax, BeautifulSoup से तेज़ है?
हाँ, साफ़ तौर पर — realistic parse-and-extract task पर BeautifulSoup(html.parser) से लगभग 12-17x तेज़ और BeautifulSoup(lxml) से 10-14x तेज़, 1 KB से 10 MB pages तक लगभग स्थिर (macOS arm64, Python 3.14)। आमतौर पर बताया जाने वाला “4-5x” html.parser के मुकाबले gap को कम आँकता है।
क्या selectolax, lxml से तेज़ है? Broadly नहीं। full parse-and-extract task में 100 KB और 1 MB पर दोनों बराबर रहे, और selectolax केवल 10 MB page पर जीता। pure parsing, बिना query के, मेरी machine पर lxml वास्तव में लगभग 33-34% तेज़ था — यह consensus के उलट परिणाम है, इसलिए इसे single-platform मानकर अपनी hardware पर verify करें।
मुझे Lexbor backend इस्तेमाल करना चाहिए या Modest?
ज़्यादातर मामलों में Lexbor — यही maintained, feature-complete engine है जिसे README recommend करती है, और इसकी CSS coverage बेहतर है। एक अपवाद वह page है जो content को <template> elements के अंदर छिपाता है, जहाँ Lexbor spec-correct तरीके से उस content को छोड़ देता है और Modest उसे पकड़ लेता है। Modest की sharp edges भी हैं, जिनमें :dir() पर hard interpreter crash शामिल है।
क्या selectolax XPath सपोर्ट करता है?
नहीं। दोनों बैकएंड xpath() method expose नहीं करते — selectolax CSS-only है। अगर आपके scrapers XPath पर निर्भर हैं, तो migration का मतलब selectors को फिर से लिखना होगा, और यही lxml- या parsel-based stack से selectolax पर जाने की सबसे बड़ी लागत है।
मेरा selectolax output बिगड़ा हुआ या elements गायब क्यों हैं?
आम तौर पर दो वजहें। अगर text replacement characters या missing accents के साथ लौट रहा है, तो संभव है आपने raw non-UTF-8 bytes दिए हों — parsing से पहले उन्हें str में decode करें (resp.content.decode("latin-1"))। अगर modern site पर links या elements गायब हैं, तो वे <template> tags के अंदर हो सकते हैं जिन्हें Lexbor backend नहीं पढ़ता; उस page के लिए Modest या कोई दूसरा parser इस्तेमाल करें।
