newspaper4k ให้ผลลัพธ์ครบ 22/22 ฟิกซ์เจอร์ของบทความที่ควบคุมไว้

ในชุดตัวอย่างที่มีการกำกับและไฮไลต์บทความชุดนี้ newspaper4k ทำได้ครบ ทั้ง 22 ฟิกซ์เจอร์ กู้คืนหน่วยบทความที่ถูกให้คะแนนได้ 98.65% และไม่แทรกโทเค็นบูตเลกที่ติดป้ายกำกับไว้เลย ทั้งสามด้านนี้ทำให้มันเป็นตัวเลือกที่แข็งแรงมากภายใต้ลำดับความสำคัญของการทดสอบครั้งนี้ แต่ก็ยังสรุปไม่ได้ว่าเป็นผู้ชนะเพียงรายเดียว

ในชุดนี้ไม่มีเครื่องมืออื่นที่ทำครบทั้งสามข้อพร้อมกันได้ Mozilla Readability กู้คืนหน่วยเนื้อหาที่ให้คะแนนได้ครบทุกหน่วย แต่กลับแทรกบูตเลกที่ติดป้ายกำกับมากกว่า; goose3 ไม่แทรกบูตเลกที่ติดป้ายกำกับเลย แต่คืนค่าว่างไปถึงสองครั้ง กฎการตัดสินแบบอื่นอาจเลือกไลบรารีตัวอื่นแทนได้

มีค่าเริ่มต้นด้านการดึงข้อมูลหนึ่งจุดที่ควรจับตาเป็นพิเศษก่อนเอาไปใช้งานจริง

newspaper4k คืออะไร

newspaper4k คือฟอร์กที่ยังมีการดูแลต่อจาก newspaper3k ซึ่งตัวมันเองเป็นเวอร์ชันต่อยอดของ Python 3 จาก newspaper รุ่นดั้งเดิม สายวิวัฒนาการนี้สำคัญเวลาคุณกำลังหาข้อมูลช่วยเหลือ เพราะสิ่งที่เจอออนไลน์ส่วนใหญ่จะอ้างถึงรุ่นต้นทาง และบางส่วนของ API ก็ถูกย้ายตำแหน่งไปแล้ว

เอกสารอ้างอิงอย่างเป็นทางการ: คลังโค้ดทางการของ newspaper4k

วิธีที่พลาดกันบ่อยที่สุดในการใช้ไลบรารีนี้คือพยายามเรียก set_html() ซึ่งเมธอดนี้ไม่มีอยู่จริง HTML ต้องส่งเข้ามาผ่าน download():

from newspaper import Article
a = Article(url="https://example.com/story")
a.download(input_html=html)     # ไม่ใช่ set_html()
a.parse()
text = a.text

ผมเองก็พลาดแบบนี้ในรอบแรก และให้คะแนนไลบรารีเป็น 0 จาก 22 ฟิกซ์เจอร์ก่อนจะกลับไปเช็กว่าความผิดอยู่ที่ผมหรือไม่ ปรากฏว่าเป็นผมเอง

สิ่งที่ได้คืนมาไม่ใช่แค่ข้อความธรรมดา Article object มีฟิลด์อย่าง text, title, authors, publish_date, top_image, images, movies, meta_description, meta_lang, tags และ article_html ส่วน keywords และ summary ต้องติดตั้ง NLP เพิ่มเติมและตั้งค่าคอร์ปัสตามที่อธิบายด้านล่าง ฟิลด์ต่าง ๆ ถูกสำรวจไว้ แต่ไม่ได้ให้คะแนนความแม่นยำของเมทาดาทา

เวอร์ชันที่ทดสอบ: 0.9.6, MIT, 1,135 GitHub stars, พร้อม push ในรีโปที่ลงวันที่ 2026-07-31 กิจกรรมที่มีวันที่กำกับนี้เป็นเพียงภาพสะท้อน ณ ช่วงเวลาหนึ่ง ไม่ใช่ข้อสรุปเต็มรูปแบบเรื่องสุขภาพการดูแลโค้ด Python 3.14.2

ผลลัพธ์

sixway-scores.json ทุกหน่วยในแต่ละฟิกซ์เจอร์มี sentinel token เฉพาะตัว ดังนั้นคำว่า “recovered” และ “leaked” จึงเป็นการตรวจการมีอยู่ของ substring แบบตรงตัว ไม่ใช่คะแนนความคล้ายคลึง Recall คำนวณจากทั้ง 22 ฟิกซ์เจอร์ ส่วน leak และ precision คำนวณจาก 11 ฟิกซ์เจอร์ที่มีทั้งบทความและบูตเลก

มีอยู่สามคอลัมน์ที่ควรแยกดูต่างหาก

มันตอบครบทุกหน้า goose3 และ jusText ทำไม่ได้ — ได้เพียง 20 และ 19 จาก 22 ตามลำดับ จุดนี้สำคัญกว่าที่เห็น เพราะค่า precision และ F1 ในตารางแบบนี้ ขึ้นกับการที่ไลบรารีต้องสร้างผลลัพธ์ก่อน: ไลบรารีที่คืนค่าว่างจะไม่ถูกนับทั้งในฝั่งใดของอัตราส่วน ดังนั้นการไม่ตอบถือว่าไม่เสียอะไร goose3 ได้ precision 1.0000 จาก 10 จาก 11 ฟิกซ์เจอร์; ส่วน newspaper4k ได้ 0.9452 จาก 11 จาก 11 จึงไม่ใช่การวัดแบบเดียวกันเสียทีเดียว

มันไม่รั่วไหลอะไรเลย ฟิกซ์เจอร์เหล่านี้มีบูตเลกที่ตั้งใจทำมาเพื่อทดสอบความทนทาน เช่น บล็อกโปรโมชันที่ถูกจัดเป็นคลาสกลาง ๆ แล้ววางเป็นพี่น้องกับบทความ เธรดคอมเมนต์ที่ใช้ชื่อคลาสธรรมดา และบล็อกโฆษณาที่ไม่ได้เขียนว่า “ad” Readability ใช้ heuristic แบบ sibling-append แล้วดูดบางส่วนเข้าไป แต่ newspaper4k ไม่เอาเลยแม้แต่ชิ้นเดียว

มันพลาดไปหนึ่งหน่วยจาก 74 และหน่วยที่พลาดนั้นก็เป็นหน่วยที่หลายตัวพลาดเหมือนกัน

จุดที่พลาดอยู่ในฟิกซ์เจอร์ที่ไม่ใช่ร้อยแก้วล้วน ๆ — หน้าเว็บที่สร้างจากตาราง โค้ดบล็อก รายการสั้น ๆ และแคปชันรูปภาพแทนที่จะเป็นย่อหน้า — และหน่วยที่หลุดไปคือ caption มันไม่ได้พลาดอยู่ตัวเดียว:

สามไลบรารีพลาด caption เดียวกันโดยไม่มีหน่วยอื่นหลุดเพิ่ม ซึ่งดูเหมือนจะไม่ใช่บั๊กคนละชุด แต่เป็นสมมติฐานที่สืบทอดร่วมกันเกี่ยวกับคุณค่าของ caption ถ้าเนื้อหาของคุณเป็นเอกสาร คู่มือสูตรอาหาร หรืออะไรที่ caption มีข้อมูลซึ่งย่อหน้าไม่มี ก็ควรทดสอบจุดนี้ก่อนตัดสินใจใช้งานจริง — และทั้ง Readability กับ jusText เก็บ caption ไว้ได้

ฟิกซ์เจอร์เดียวกันนี้ยังเป็นจุดที่ goose3 พังหนักที่สุด เพราะเสียไปถึงสามในสี่ของหน้า ดังนั้น “เนื้อหาที่ไม่ใช่ร้อยแก้ว” จึงเป็นแกนที่ทั้งหกเครื่องมือแตกต่างกันมากกว่าที่ตารางหัวข้อจะบอก

ด้านความเร็ว newspaper4k มี median extraction จากทั้ง 22 ฟิกซ์เจอร์ที่ 2.69 ms ซึ่งช้าที่สุดในทั้งหกตัว และค่าสูงสุดอยู่ที่ 199.81 ms เมื่อเทียบกับ median 0.06 ms ของ resiliparse แล้วต่างกันถึง 45 เท่าในรันที่ควบคุมนี้ median อาจดูเล็กในเวิร์กโฟลว์ที่ประมวลผลทีละหน้า แต่ยังไม่ได้ทดสอบ throughput และ tail latency ภายใต้โหลด ส่วน cold import จะวัดต่างหากด้านล่าง

ค่าเริ่มต้นที่ผมจะเปลี่ยนตั้งแต่บรรทัดแรก

เอกสารอ้างอิงอย่างเป็นทางการ: เอกสารของ newspaper4k

เมื่ออ่านออบเจ็กต์ Configuration ที่มากับแพ็กเกจ จะเจอค่าตั้งไว้ทั้งหมด 22 รายการ และหนึ่งในนั้นคือ

_honor_robotstxt = False

newspaper4k จะไม่เคารพ robots.txt เว้นแต่คุณจะสั่งไว้เอง ถ้าคุณปล่อยให้มันดึงข้อมูล — Article(url).download() โดยไม่ส่ง input_html — มันจะไปดึงทุก URL ที่คุณชี้ให้ โดยไม่สนใจว่าไฟล์ robots ของเว็บนั้นว่าอย่างไร

ในเชิงวิศวกรรม นี่เป็นค่าเริ่มต้นที่พอรับได้สำหรับไลบรารีที่จุดประสงค์หลักคือ parse HTML ที่คุณมีอยู่แล้ว แต่ก็เป็นค่าที่ไม่ควรมารู้เอาใน production หลังจากคุณชี้ไปที่ URL เป็นพัน ๆ รายการแล้ว ตั้ง honor_robotstxt=True บน Configuration หรือส่ง input_html แล้วจัดการ fetch เอง ซึ่งเป็นวิธีที่ผมใช้ตลอดการทดสอบนี้

อีกสองค่าที่ควรรู้ไว้:

number_threads = 10. ค่า parallelism เริ่มต้นสำหรับ helper ที่จัดการหลายบทความพร้อมกันคือ 10 ซึ่ง concurrency ไม่ได้แปลว่า requests ต่อวินาทีโดยตรง แต่ก็อาจทำให้มีคำขอจำนวนมากเกิดขึ้นพร้อมกัน หากคุณไม่ได้กำหนดลิมิตและการจัดตารางต่อโฮสต์ไว้ชัดเจน

fetch_images = True. การดึงรูปภาพเปิดไว้เป็นค่าเริ่มต้น ซึ่งทำให้เกิดคำถามเรื่องการใช้งานแบบออฟไลน์ เมื่อบล็อก socket.connect ไว้ เส้นทางที่ทดสอบของ newspaper4k 0.9.6 — download(input_html=…) ตามด้วย parse() บนอินพุต HTML ที่ถือไว้หนึ่งชุด — ทำงานจบ คืนค่า 1,292 ตัวอักษร และพยายามเชื่อมต่อเครือข่าย 0 ครั้ง สิ่งนี้ยืนยันเฉพาะเส้นทางดังกล่าว ไม่ได้ยืนยันทุก configuration, plugin, ประเภทคอนเทนต์ หรือรีลีสในอนาคต

ค่าที่เหลือก็สมเหตุสมผล: min_word_count 300, min_sent_count 7, max_text 100,000, http_success_only True, memorize_articles True, follow_meta_refresh False, allow_binary_content False

ความจริงของการติดตั้ง

pip install newspaper4k ดึง 22 แพ็กเกจ และ 47.5 MiB ใช้เวลาประมาณหกวินาที การ import แบบ cold ใน subprocess ใหม่: 2.812 s — ช้าที่สุดในชุดเปรียบเทียบ

install-and-import.json แต่ละไลบรารีอยู่ใน virtualenv ว่างของตัวเอง ดังนั้นไม่มีอะไรสืบทอด dependency จากตัวอื่น

การ import ใช้เวลา 2.812 วินาที ซึ่งมากกว่า resiliparse 15 มิลลิวินาทีถึง 187 เท่า ถ้าเป็น worker ที่รันยาว คุณจ่ายต้นทุนนี้ครั้งเดียวแล้วแทบไม่สำคัญ แต่ถ้าเป็น serverless function คุณต้องจ่ายทุก cold start และในกรณีนั้น newspaper4k จึงไม่ใช่ตัวเลือกที่เหมาะ ไม่ว่าคุณภาพการแยกเนื้อหาจะดีแค่ไหน

มีจุดสะดุดเล็ก ๆ ตอนติดตั้ง โดยตอน import จะมีคำเตือน:

UserWarning: nltk is not installed. Some NLP features will be unavailable. Install it with: pip install 'newspaper4k[nlp]'

การทดสอบนี้ไม่ได้ใช้ฟีเจอร์เหล่านั้น และการแยกเนื้อหาก็ทำงานได้ปกติแม้ไม่มีมัน แต่การติดตั้งพื้นฐานไม่ใช่การติดตั้งที่ครบทั้งหมด และ newspaper4k[nlp] จะดึง dependency ที่หนักขึ้นมากรวมถึงการดาวน์โหลดคอร์ปัสด้วย ควรเผื่องบไว้เฉพาะเมื่อคุณต้องการ keywords และ summaries จริง ๆ

หน่วยความจำ และ HTML ที่เสียหายมีผลอย่างไร

สองเรื่องที่ทุกรายงานในชุดนี้เคยบอกว่าไม่ได้ทดสอบ ตอนนี้มีการวัดแล้ว

บริบทการทดสอบความทนทานที่กว้างกว่านี้อยู่ใน การเปรียบเทียบหน่วยความจำและ HTML ที่เสียรูปแบบของสิบไลบรารี

หน่วยความจำ resident สูงสุด วัดผ่าน /usr/bin/time -l โดยใช้โปรเซสใหม่หนึ่งตัวต่อหนึ่งเซลล์ — ค่า floor ตอน import คือสิ่งที่ไลบรารีใช้เมื่อโหลดแล้วแต่ไม่ได้ทำงาน ส่วนค่าสูงสุดรวมเอกสารเข้าไปด้วย

memory-results.json ฐานของ Python และ Node เปรียบเทียบกันตรง ๆ ไม่ได้ เพราะตัว interpreter อยู่ในทั้งสองฝั่ง

ค่า floor ของ newspaper4k คือ 52.6 MiB และ peak ตอนประมวลผลไฟล์ 10 MB คือ 668.5 MiB — หนักเป็นอันดับสองในบรรดาไลบรารี Python ตัวเลขเหล่านี้ไม่ใช่ปัญหาสำหรับหน้าเว็บทั่วไป แต่มีความหมายมากถ้าคุณประมวลผลเอกสารขนาดใหญ่แบบ batch ใน worker ที่จำกัดหน่วยความจำ

HTML ที่เสียหาย มีเอกสาร 12 ชุดที่แต่ละชุดทำให้เสียหายเพียงอย่างเดียว — แท็กไม่ปิด, inline elements ซ้อนผิด, attributes ไม่ใส่เครื่องหมายคำพูดแต่มีช่องว่าง, closing tag โผล่มาเกิน, ไม่มี <html> เลย, attributes ซ้ำ, เอกสารถูกตัดกลางแท็ก, entities ผิด, <script> ที่ไม่ปิด, การประกาศ charset ที่โกหก, คอมเมนต์ที่มี markup อยู่ข้างใน, และการซ้อนกัน 600 ชั้น — บวกกับ ตัวควบคุมที่ถูกต้องสองชุดที่มีขนาดเท่ากัน เพราะคำว่า “มันไม่คืนอะไรเลย” จะบอกเรื่อง malformedness ได้ก็ต่อเมื่อไลบรารีไม่ได้เงียบกับเอกสารที่สะอาดและมีขนาดใกล้เคียงกันด้วย

ผลของตัวควบคุมและกรณี malformed แยกจากกันชัดเจนในผลดิบ:

ตัวควบคุมสองชุดให้ผล 70 และ 1,351 ตัวอักษร ขณะที่อินพุต malformed 10 จาก 12 ชุดคืนค่าว่างทั้งหมด ทำให้การเงียบของผลลัพธ์ในงานออกแบบฟิกซ์เจอร์นี้น่าจะมาจากความเสียหายของ HTML จริง ๆ ไม่ใช่เพราะอินพุตสั้นเกินไป ตัว scorer จะตรวจ sentinel ของ heading, paragraph และ link ในเอกสาร malformed ที่เข้าเงื่อนไขทั้ง 11 ชุด ส่วนฟิกซ์เจอร์ unclosed-<script> ถูกตัดออก เพราะตามการ parse แบบ HTML5 markup ที่ตามมาจะยังถูกมองว่าเป็นเนื้อหาของ script ดู malformed-results.json นี่เป็นข้อจำกัดด้านการกู้คืนที่ควรนำไปพิจารณาเวลาเลือกใช้ ไม่ใช่แค่ความสำเร็จแบบ “ไม่เกิดข้อยกเว้น” เท่านั้น

ข้อดีและข้อเสีย

ข้อดี ไม่มีโทเค็นบูตเลกที่ติดป้ายกำกับในชุดเปรียบเทียบนี้ สร้างผลลัพธ์ได้ครบทั้ง 22 ฟิกซ์เจอร์ของบทความ และมี scored article recall 0.9865 มีการเปิดเผยทั้ง text ของบทความและฟิลด์เมทาดาทา แม้จะไม่ได้ทดสอบความแม่นยำของเมทาดาทา เส้นทาง held-HTML ที่ทดสอบไม่มีการพยายามเชื่อมต่อเครือข่ายเมื่อบล็อก socket.connect และตอนตรวจรีโปมี push ที่ลงวันที่ค่อนข้างใหม่ อย่างไรก็ดีไม่ได้ประเมินสุขภาพการดูแลโค้ดในภาพรวม

ข้อเสีย cold import หนักที่สุดในชุดที่ 2.812 วินาที และ site-packages ที่วัดได้ 47.5 MiB / 22 แพ็กเกจ honor_robotstxt ตั้งต้นเป็น False และ helper ที่รองรับหลายบทความพร้อมกันก็ใช้ 10 threads เป็นค่าเริ่มต้น แพ็กเกจพื้นฐานมีคำเตือนเรื่อง NLTK หายไป ดังนั้น keywords และ summaries ต้องติดตั้งเสริมที่หนักกว่า สิ่งสำคัญที่สุดคือ 10 จาก 12 ฟิกซ์เจอร์ malformed คืนค่าเป็นค่าว่าง แม้ตัวควบคุมที่ถูกต้องทั้งสองชุดจะยังให้ข้อความออกมา

ใครควรใช้ และใครไม่ควรใช้

ควรพิจารณา newspaper4k เมื่อคุณเรียงลำดับความสำคัญเป็น: ต้องการให้ได้ข้อความไม่ว่างจากคอร์ปัสบทความที่ควบคุมไว้, ลดบูตเลกที่ติดป้ายกำกับในคอร์ปัสดังกล่าวให้มากที่สุด, และยอมรับ cold import ที่ช้าลง ภายใต้กฎแบบนี้ มันเป็นผู้นำของการเปรียบเทียบชุดฟิกซ์เจอร์นี้ แต่ถ้าใช้กฎคนละแบบ คุณอาจเลือก Readability เพื่อเก็บเนื้อหาได้มากที่สุด หรือ resiliparse เพื่อความเร็วตอนเริ่มต้นและ median extraction ที่ดีกว่า

ควรข้าม หรืออย่างน้อยต้อง bake-test อย่างรอบคอบ เมื่อ cold start เป็นตัวกำหนดหลัก, เมื่อ site-packages ขนาด 47.5 MiB มีนัยสำคัญ, หรือเมื่อการกู้คืนจาก HTML ที่เสียรูปแบบเป็นเรื่องสำคัญ resiliparse import เร็วกว่าที่นี่ถึง 187 เท่า แต่ก็ไม่ได้ชนะ trafilatura ทุกคอลัมน์ด้านคุณภาพ: trafilatura มี article recall สูงกว่า ขณะที่ลักษณะการรั่วไหลและ precision ก็แตกต่างกัน newspaper4k ออกแบบมาสำหรับบทความเป็นหลัก; รายการสินค้าและแดชบอร์ดไม่ได้ถูกทดสอบ ดังนั้นจึงยังไม่มีคำกล่าวอ้างเกี่ยวกับพฤติกรรมในงานเหล่านั้น

ไม่ว่าจะทำอะไร อย่าลืมตั้ง honor_robotstxt ถ้าคุณให้มัน fetch เอง นี่ไม่ใช่หมายเหตุด้านประสิทธิภาพ

บทบาทของ API แบบจัดการให้

newspaper4k สามารถ parse HTML ที่ผู้เรียกส่งมาให้ และยังมีเส้นทางการ fetch ของตัวเองด้วย บริการ extraction แบบจัดการให้จะย้ายภาระการดึงข้อมูล การ render และงาน schema ไปอยู่หลังขอบเขตของผู้ให้บริการแทน เราสร้าง Thunderbit ขึ้นมา แต่ไม่ได้รันมันกับชุดฟิกซ์เจอร์นี้ ดังนั้นรีวิวนี้จึงไม่สามารถสรุปเปรียบเทียบเรื่องคุณภาพ การ render การต้านบอท ความหน่วง หรือค่าใช้จ่ายได้ สำหรับ held article HTML หลักฐานในที่นี้พูดถึงเฉพาะ newspaper4k เท่านั้น; เป้าหมายที่ไม่ใช่บทความต้องมีการประเมินของตัวเอง

สำหรับผลลัพธ์ชุดเดียวกันนี้เมื่อเทียบข้ามทั้งหกตัวแยกข้อความ ดู การเปรียบเทียบ article extraction ทั้งหกไลบรารี

สำหรับฝั่งบริการแบบโฮสต์ บทสรุป web scraping API roundup ให้ภาพกว้างกว่า; ถ้าเป็นทางเลือกแบบ self-hosted ดู open-source scraper pillar และถ้าข้อความจะถูกส่งเข้าโมเดล การแปลง HTML เป็น Markdown ใน Python จะอธิบายว่าความเที่ยงตรงหายไปตรงไหน

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ

ควรใช้ newspaper4k ไหม?

ให้มอง newspaper4k เป็นตัวเลือกที่แข็งแรงสำหรับการดึงข้อความจากบทความเมื่อคุณมี HTML อยู่แล้ว จากนั้นควรทดสอบกับเว็บไซต์จริงบนคอร์ปัสของคุณก่อนตัดสินใจใช้จริง ชุดที่ควบคุมไว้บ่งชี้ว่ามันมี scored article recall สูง ไม่มีบูตเลกที่ติดป้ายกำกับ และสร้างผลลัพธ์ไม่ว่างได้ครบทั้ง 22 ฟิกซ์เจอร์ที่เน้นบทความ อย่างไรก็ตาม ชุดนี้ไม่ได้ครอบคลุมหน้าเว็บจริงหรือความแม่นยำของเมทาดาทา และ 10 จาก 12 ฟิกซ์เจอร์ malformed ก็คืนค่าเป็นค่าว่าง

ถ้าคุณใช้เส้นทางการ fetch ของมัน ให้ทบทวน honor_robotstxt=False, การทำงานแบบ 10 threads และการควบคุม rate ต่อโฮสต์อย่างชัดเจน หาก cold start หรือ footprint ของ dependency มีความสำคัญ ให้เอาค่าการ import 2.812 วินาทีและ site-packages 47.5 MiB ไปวัดใน deployment ของคุณจริง ๆ แทนที่จะถือว่าเป็นต้นทุนคอนเทนเนอร์แบบทั่วไป

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

ทำไม set_html() ถึงใช้ไม่ได้? เพราะใน newspaper4k ไม่มีเมธอดนี้ HTML ต้องส่งผ่าน download(input_html=html) แล้วค่อย parse() ผลค้นหาบนเว็บอาจแสดงตัวอย่างจาก newspaper3k ทำให้สับสนได้ง่าย ผมเองก็พลาดในรอบแรก และแก้ harness ก่อนเริ่มให้คะแนน

newspaper4k เคารพ robots.txt หรือไม่? ไม่เคารพโดยค่าเริ่มต้น honor_robotstxt ถูกตั้งเป็น False ตั้งเป็น True ใน Configuration หากคุณปล่อยให้ไลบรารี fetch เอง หรือส่ง input_html แล้ว fetch ด้วยตัวคุณเอง งานแบบหลายบทความยังตั้งต้นที่ 10 threads ด้วย นั่นคือความขนานที่ไม่ได้เลือกเอง ไม่ใช่อัตราคำขอคงที่ ดังนั้นควรกำหนดลิมิตต่อโฮสต์ให้ชัดเจนเมื่อ fetch

parse() ส่งคำขอเครือข่ายหรือไม่? บน newspaper4k 0.9.6 เส้นทาง download(input_html=…) ตามด้วย parse() ที่ทดสอบนี้ไม่พยายามเชื่อมต่อใด ๆ กับอินพุต HTML ที่ถือไว้หนึ่งชุด ขณะที่ socket.connect ถูกบล็อกอยู่ อย่างไรก็ตามสิ่งนี้ไม่ได้พิสูจน์ว่าทุกการตั้งค่า parser, plugin, ประเภทคอนเทนต์ หรือรีลีสในอนาคตจะไม่แตะเครือข่าย

คำเตือน NLTK ตอน import คืออะไร? แพ็กเกจพื้นฐานไม่ได้รวม NLTK ไว้ ดังนั้นการดึง keyword และการสรุปข้อความจะใช้งานไม่ได้ และไลบรารีจะแจ้งเช่นนั้นตั้งแต่ตอน import แต่การแยกเนื้อหาไม่กระทบ — ทุกอย่างที่วัดในที่นี้รันบนแพ็กเกจพื้นฐาน pip install 'newspaper4k[nlp]' จะเพิ่มฟีเจอร์เหล่านั้นพร้อม dependency tree ที่หนักขึ้นและการดาวน์โหลดคอร์ปัส

รีวิวนี้ไม่ได้ทดสอบอะไรบ้าง? หน้าเว็บจริง — ทั้งหมดนี้เป็นฟิกซ์เจอร์ที่ควบคุมและมีหน่วยกำกับไว้ เมทาดาทาถูกสำรวจแต่ไม่ได้ให้คะแนนความแม่นยำของ title, author, date หรือ image การดึงหลายภาษา, ส่วนเสริม NLP, การ crawl แหล่งข้อมูลแบบหลายเธรด และ throughput ภายใต้โหลดก็ไม่ได้ทดสอบเช่นกัน peak memory ของโปรเซสถูกวัดจาก HTML ขนาด 226 KB และ 10 MB อย่างละหนึ่งอินพุต ไม่ได้วัดภายใต้ concurrency หรือโหลดต่อเนื่อง