โปรดทราบว่า PyPy ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคัก

 (github.com/astral-sh)
3 คะแนน โดย GN⁺ 2026-03-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการรวมการเปลี่ยนแปลงใน repo ของ uv ที่ระบุไว้ในเอกสารอย่างชัดเจนว่า PyPy ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคัก
  • ผู้เสนอระบุว่า PyPy กำลังถูกทยอยตัดออก โดยอ้างอิงจาก issue ของโปรเจกต์ numpy
  • ในเอกสารถูกเพิ่ม ข้อความเตือน ว่า “PyPy ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคักอีกต่อไป และรองรับถึง Python 3.11 เท่านั้น”
  • หลังจากนั้นในชุมชน นักพัฒนา PyPy ได้แสดง ความเห็นโต้แย้ง ว่า “ยังคงมีการบำรุงรักษาอยู่ แต่ด้วยกำลังคนที่ไม่เพียงพอจึงติดตามเวอร์ชัน CPython ได้ยาก”
  • ฝั่งโปรเจกต์ได้ปรับถ้อยคำจากเดิม “unmaintained” เป็น “not actively developed” เพื่อ สะท้อนสถานการณ์ได้แม่นยำยิ่งขึ้น

ภาพรวมของ Pull Request

  • konstin ได้สร้าง PR เพื่อเพิ่ม ข้อความเตือนเกี่ยวกับ PyPy ลงในเอกสารของโปรเจกต์ uv
    • โดยระบุเหตุผลว่า “PyPy ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคักอีกต่อไป และกำลังถูกทยอยตัดออกจาก numpy”
    • แม้จะไม่มีแถลงการณ์อย่างเป็นทางการ แต่ก็อธิบายว่า issue ที่เกี่ยวข้องใน numpy ถูกเปิดโดย นักพัฒนา PyPy
  • มีการเพิ่มข้อความต่อไปนี้ลงในเอกสาร (docs/concepts/python-versions.md)
    • “PyPy ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคักอีกต่อไป และรองรับถึง Python 3.11 เท่านั้น”
  • PR นี้ประกอบด้วย 4 commits และถูกรวมเข้ากับสาขา main เมื่อวันที่ 22 มกราคม 2026

การถกเถียงในชุมชน

  • ผู้มีส่วนร่วมบางรายชี้ว่า ข้อความเตือนดูซ้ำซ้อน และต่อมาจึงมีการแก้ไขให้แสดงเพียงครั้งเดียว
  • หลังการ merge ชุมชน PyPy และนักพัฒนาภายนอก ได้แสดงปฏิกิริยาผ่านคอมเมนต์บน GitHub
    • stuaxo อ้างคำพูดของนักพัฒนา PyPy และระบุว่า “PyPy ยังมีการบำรุงรักษาอยู่ เพียงแต่ช้ากว่า CPython”
    • Foxboron ถามว่า “ได้ติดต่อผู้ดูแล PyPy ก่อน merge หรือไม่”
    • vitorsr อ้างคำพูดของ mattip นักพัฒนาหลักของ PyPy ว่า “ต้องการผู้ร่วมพัฒนาและการสนับสนุนด้านการเงิน”
  • HaoZeke ระบุว่า “การ merge โดยไม่มีการหารือเป็นสิ่งที่ไม่เหมาะสม” และ ขอให้ถอน PR นี้

การตอบสนองจากฝั่งโปรเจกต์

  • charliermarsh อธิบายว่าได้เปลี่ยนชื่อ PR จาก “unmaintained” เป็น “not actively developed”
  • zanieb ชี้แจงว่า “ใน issue ของ numpy นักพัฒนาหลักของ PyPy เป็นผู้ระบุเองว่า ‘ไม่ได้มีการพัฒนาอย่างต่อเนื่องอย่างคึกคัก’” พร้อมอธิบายว่า ไม่ได้มีเจตนาร้าย
  • mattip (นักพัฒนาหลักของ PyPy) ระบุว่า “ถ้อยคำปัจจุบันสะท้อนสถานการณ์ได้อย่างเป็นธรรม” และ เห็นด้วยให้คงข้อความนี้ไว้
    • อย่างไรก็ตาม ได้กล่าวเพิ่มเติมว่าหาก PyPy อัปเดตเป็น Python 3.11.15 ก็อาจ ย้อน PR นี้กลับได้

ผลกระทบหลังการ merge

  • การเปลี่ยนแปลงนี้ถูกรวมอยู่ในรีลีส uv 0.9.27 และสะท้อนออกมาเป็นการอัปเดตเอกสาร
  • Homebrew และบอตอัตโนมัติหลายตัวได้อ้างอิง PR นี้ ทำให้ คำเตือนเกี่ยวกับ PyPy ถูกรวมอยู่ในเอกสารทางการ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-10
ความเห็นจาก Hacker News
  • ฉันเป็นนักพัฒนาแกนหลักของ PyPy ถ้าใครอยากช่วยไม่ว่าจะเป็นด้านการเงินหรือร่วมเขียนโค้ด แนะนำให้ดูช่องทางติดต่อ
    • อยากให้ในเว็บไซต์มีส่วนบริจาคที่สังเกตเห็นได้ชัดเจนกว่านี้ การมีระดับผู้สนับสนุนแบบเป็นขั้น ๆ เหมือนเบราว์เซอร์ Ladybird ก็น่าจะดี ฉันเองก็อยากบริจาคเงินเล็กน้อย แต่หาว่าต้องทำที่ไหนได้ยาก
    • เมื่อกี้นี้บริจาคแล้ว ขอบคุณทุกคนในทีม PyPy ฉันใช้ PyPy บ่อยมากในแอปของตัวเอง และในงานที่คำนวณหนัก ๆ มันมักเร็วกว่า CPython มากกว่า 5 เท่า สิ่งที่ใช้เวลา 5 นาทีบน CPython จบบน PyPy ได้ในไม่กี่วินาที
    • มีอีกข้อเสนอหนึ่ง ฉันรู้ว่า PyPy เร็วในงานที่เป็น CPU-bound แต่คิดว่าน่าจะแสดงประสิทธิภาพที่ดีขึ้นได้ในงาน I/O-bound ด้วย น่าจะมีหน้า benchmark อย่างเช่น throughput ของการจัดการ HTTP request เพื่อเทียบ asyncio กับ CPython และถ้ามีเครื่องมืออัตโนมัติที่วัดประสิทธิภาพของ PyPy บนเว็บได้โดยตรงก็น่าสนใจ
    • บนเว็บมีข้อความหยุดบำรุงรักษาแล้วแสดงอยู่เด่นมาก
  • PyPy ไม่ใช่โปรเจ็กต์ที่หยุดบำรุงรักษาแล้ว ยังมีการแก้บั๊กและปรับปรุง JIT อย่างต่อเนื่อง เพียงแต่นักพัฒนาแกนหลักที่เหลืออยู่มีไม่พอจะตามความเร็วของการเปลี่ยนแปลงใน CPython ให้ทัน ต้องการผู้ร่วมพัฒนาใหม่เพื่อรองรับเวอร์ชันใหม่ ๆ โชคดีที่งานรองรับ 3.12 มีผู้ร่วมพัฒนาใหม่กำลังทำอยู่
    • ตอนนี้ CPython กลายเป็นเหมือนโปรเจ็กต์เชิงพาณิชย์ไปแล้ว นักพัฒนาบางคนกีดกันคนอื่น และโปรเจ็กต์ที่เดินด้วยเงินทุนบริษัทจำนวนหนึ่งก็มักหายไปในอีก 5 ปีต่อมา คนเก่ง ๆ ก็ออกไปหมดแล้ว การเขียน unicodeobject.c ใหม่เป็นครั้งที่ 150 ยังพอว่าได้ แต่นอกนั้นตามไม่ทันจริง ๆ
    • ข้อความที่ถูกรวมลงในเอกสารกระชับกว่าชื่อ PR — เขียนว่า “ไม่ได้ถูกพัฒนาอย่างแข็งขันอีกต่อไป”
  • PyPy เป็นความสำเร็จที่น่าทึ่งจริง ๆ ทีม Faster CPython ของ Microsoft ใช้เวลา 4 ปีแต่ได้ดีขึ้นเพียง 1.5 เท่า ขณะที่ PyPy เร็วกว่า 5 เท่ามาได้หลายสิบปีแล้ว แต่ดูเหมือนเป้าหมายหลักของ PyPy จะใกล้เคียงกับการเป็นโปรเจ็กต์วิจัยมากกว่า (เช่น meta-tracing, STM) และทีม CPython ก็ไม่ได้สนใจ implementation อื่น ๆ มากนัก เลยยิ่งไม่ได้รับความสนใจ
    • ความสำเร็จของ ecosystem Python มาจากไลบรารี C extensionอย่าง SciPy, pandas, TensorFlow เป็นหลัก CPython มี C API ที่ทำให้ไลบรารีเหล่านี้เร่งความเร็วได้ง่าย CFFI ของ PyPy ไม่น่าดึงดูดพอสำหรับโปรเจ็กต์ใหญ่ ๆ ส่วน HPy ก็ออกมาช้าเกินไป ตอนที่แรงส่งของ PyPy หายไปแล้ว
    • โปรเจ็กต์ Faster Python อาจไปได้ไกลกว่านี้ แต่ Microsoft เลิกทำไปเพราะปีที่แล้วมัวไล่ตามกระแส AIและปลดพนักงานทีมภาษาจำนวนมาก
    • เราใช้PyPy ในโปรดักชันมานานกว่า 10 ปีในองค์ประกอบของระบบหลัก
    • PyPy ยอดเยี่ยมมากใน benchmark แต่ในการพัฒนาขนาดใหญ่จริง ๆ มีปัญหาความเข้ากันได้มากเกินไป คนส่วนใหญ่ทึ่งกับผลทดสอบประสิทธิภาพ แต่พอใช้กับแอปจริงกลับล้มเหลว GC เป็นแบบlazy ทำให้ทรัพยากรอย่าง file descriptor ไม่ถูกคืนตามเวลาและเกิด resource exhaustion ได้ง่าย ปัญหาคือความแตกต่างสำคัญแบบนี้ไม่ได้ถูกบันทึกไว้ในเอกสาร
  • ถ้าชื่อทำให้สับสน ขอสรุปว่า PyPI คือ Python package index ส่วน PyPy คือ “implementation ทางเลือกของ Python ที่เร็วและเข้ากันได้สูง” เพียงแต่ตอนนี้การออกรีลีสเวอร์ชัน 3.12 ล่าช้าเพราะขาดนักพัฒนา (การสนทนาที่เกี่ยวข้อง)
    • ขอบคุณสำหรับคำอธิบาย โดยเฉพาะใน issue ของ repository uv ที่มีการปนกันระหว่าง PyPi กับ PyPy เลยยิ่งงง
    • ทำให้นึกถึงความสัมพันธ์ระหว่าง Cython กับ CPython
    • mypy คือ “static type checker สำหรับ Python” ส่วน RPython ของ PyPy ก็เกี่ยวข้องกับ static type เหมือนกัน สมัยก่อนฉันเลยมักสับสนสองอย่างนี้ ตอนหลังเพิ่งรู้จัก mypyc เลยรู้สึกเหมือนจิ๊กซอว์ในหัวต่อกันครบ
    • การตั้งชื่อนี่แย่มากจริง ๆ
  • น่าสนใจที่ข้อความ “ไม่ได้ถูกพัฒนาอย่างแข็งขันอีกต่อไปในฐานะโปรเจ็กต์อาสาสมัคร” ถูกเปลี่ยนเป็น “หยุดบำรุงรักษาแล้ว”
    • เพื่ออ้างอิง PyPy มีคอมมิตเดือนละ 2–4 ครั้งมาตั้งแต่ตุลาคมปีที่แล้ว และรีลีสล่าสุดคือเดือนกรกฎาคม 2025 (ประวัติคอมมิต, รายการแท็ก)
    • ฉันเคารพผู้ร่วมพัฒนา PyPy มาก แต่การบอกว่า “หยุดบำรุงรักษาแล้ว” ก็ดูเป็นคำอธิบายที่ค่อนข้างยุติธรรม
  • ถ้า PyPy หายไปก็คงน่าเสียดายมาก หวังว่าผลงานวิจัยที่มีประโยชน์ตลอดหลายปีจะถูกย้ายไปยัง CPython แล้ว
    • REPL แบบ Python ล้วนที่เริ่มจาก PyPy ถูกนำไปขัดเกลาใน CPython และบทเรียนจาก HPy ก็กำลังค่อย ๆ ถูกนำไปใช้ใน CPython นอกจากนี้ PyPy ยังช่วยให้มีการแก้บั๊กเล็ก ๆ จำนวนมากใน standard library ของ CPython
    • แต่แนวทางต่างกันโดยสิ้นเชิง ดังนั้นเทคโนโลยีส่วนใหญ่คงไม่ได้ถูกพอร์ตไปยัง CPython โดยตรง
  • ฉันอ่านเป็น PyPi แล้วใจหายวาบไปเลย
  • ตอนนี้อาจจะดีกว่าถ้าเอาเวลาและเงินไปลงกับRustPython (เว็บไซต์ทางการ, GitHub)
    • แต่ RustPython ช้ากว่า CPython แล้วจะมีเหตุผลอะไรให้ใช้ล่ะ
  • ท้ายที่สุดแล้วสิ่งที่ขับเคลื่อนการพัฒนาคือเงิน ทำไมถึงยังไม่มีระบบที่บริจาคให้นักพัฒนาทั้งต้นไม้ dependency ได้ ปัญหาแบบนี้ถ้าสะสมไปเรื่อย ๆ สุดท้ายก็คงทำให้การบำรุงรักษายากขึ้น
  • ขอบคุณทีม PyPy สำหรับความพยายามทั้งหมด ฉันเองก็จะลองหาทางช่วยดู