Pyrefly - ตัวตรวจสอบชนิดข้อมูลและประสบการณ์ IDE แบบใหม่สำหรับ Python

 (engineering.fb.com)
7 คะแนน โดย GN⁺ 2025-05-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Pyrefly ของ Meta เป็นทั้ง ตัวตรวจสอบชนิดข้อมูลของ Python แบบโอเพนซอร์สและส่วนขยาย IDE ที่พัฒนาด้วย Rust
  • รองรับประสิทธิภาพการวิเคราะห์ที่รวดเร็วมากและความสามารถด้าน การผสานรวมกับ IDE โดยพัฒนาขึ้นเพื่อก้าวข้ามข้อจำกัดของ Pyre
  • ยึดหลัก การอนุมานชนิดข้อมูลอัตโนมัติ การรองรับโค้ดเบสขนาดใหญ่ และแนวคิดโอเพนซอร์สเป็นหัวใจสำคัญ
  • มีเป้าหมายปรับปรุง ระบบชนิดข้อมูล ของทั้งระบบนิเวศผ่านการทำงานร่วมและการมีส่วนร่วมกับชุมชน Python
  • ขณะนี้เปิดตัวเวอร์ชันอัลฟาแล้ว และกำลังขอรับฟีดแบ็กและการมีส่วนร่วมจากชุมชนอย่างจริงจัง

บทนำ

  • Pyrefly เป็นโปรเจ็กต์โอเพนซอร์สของ Meta ที่เป็นทั้ง ตัวตรวจสอบชนิดข้อมูลแบบสแตติกสำหรับ Python และส่วนขยาย IDE ที่พัฒนาด้วย Rust
  • ช่วยรองรับ การตรวจพบข้อผิดพลาดล่วงหน้า โดยตรวจสอบความสอดคล้องของชนิดข้อมูลก่อนรันโค้ด
  • ใช้งานได้ทั้งแบบผสานกับ IDE และผ่าน CLI จึงมอบ เวิร์กโฟลว์ที่ยืดหยุ่น
  • ตั้งเป้ามีส่วนช่วยพัฒนาระบบชนิดข้อมูลของ Python และไลบรารีต่าง ๆ ผ่านความร่วมมือกับชุมชนโอเพนซอร์ส

เบื้องหลังการพัฒนา Pyrefly

  • ในปี 2017 Meta ได้พัฒนาตัวตรวจสอบชนิดข้อมูลตัวใหม่สำหรับ โค้ดเบส Python ขนาดใหญ่ของ Instagram ซึ่งต่อมากลายเป็น Pyre
  • Pyre อ้างอิงการออกแบบที่แข็งแกร่งจาก Hack, Flow และพัฒนาด้วย OCaml เพื่อประสิทธิภาพ
  • เมื่อเวลาผ่านไป ความต้องการด้าน การพัฒนาระบบชนิดข้อมูล และการเชื่อมต่อกับ IDE เพิ่มขึ้น จึงเริ่มเห็นข้อจำกัด
  • แม้จะใช้เครื่องมือจากชุมชนอย่าง Pyright ด้วย แต่ยังมีข้อจำกัดในการตอบโจทย์เรื่องการสำรวจโค้ดขนาดใหญ่ การส่งออกชนิดข้อมูล และความต้องการอื่น ๆ จึงเริ่มพัฒนา Pyrefly

หลักการสำคัญของ Pyrefly

  • 1. ประสิทธิภาพ

    • นักพัฒนาต้องการ การตรวจสอบชนิดข้อมูลที่รวดเร็วทุกครั้งที่พิมพ์ ทันทีหลังเขียนโค้ด
    • Pyrefly ใช้สถาปัตยกรรม Rust ประสิทธิภาพสูง ที่สามารถตรวจสอบโค้ดเบสขนาดใหญ่มากได้ถึง 1.8 ล้านบรรทัดต่อวินาที

  • 2. การออกแบบที่ยึด IDE เป็นศูนย์กลาง

    • มีการออกแบบเชิงนามธรรมตั้งแต่ต้นเพื่อให้ IDE และ CLI มองเห็นสถานะเดียวกัน
    • ใน Pyre สิ่งนี้เป็นการเติมภายหลัง แต่ใน Pyrefly ได้เน้นความสอดคล้องตั้งแต่ขั้นตอนการออกแบบ

  • 3. Inference (การอนุมาน)

    • รองรับ การอนุมานชนิดข้อมูลอัตโนมัติ แม้ในโค้ด Python ที่ไม่ได้ระบุชนิดข้อมูลและไม่มีคอมเมนต์กำกับ
    • สามารถแสดงชนิดข้อมูลของค่าที่คืนกลับและตัวแปรภายในบน IDE และเพื่อช่วยให้เขียนโค้ดได้ดีขึ้น ยังสามารถ แทรกชนิดข้อมูลที่อนุมานได้อัตโนมัติเมื่อดับเบิลคลิก

  • 4. โอเพนซอร์ส

    • Pyrefly เผยแพร่บน GitHub ภายใต้สัญญาอนุญาต MIT และยินดีรับ PR จากชุมชนรวมถึงการแจ้งปัญหา
    • มุ่งสร้างการสื่อสารอย่างคึกคักผ่านช่องทาง Discord พร้อมเชื่อมโยงกับระบบนิเวศ Python และไลบรารีหลักของ Meta เช่น PyTorch

อนาคตของ Pyrefly

  • กำลังเดินหน้าร่วมกับชุมชนโดยมีเป้าหมายเพื่อ ปรับปรุงภาษา Python และประสบการณ์ของนักพัฒนา
  • ตั้งแต่ช่วงแรกของการพัฒนา Pyre ก็มีการเปิดซอร์สโค้ดและมีส่วนร่วมกับ PEP อย่างต่อเนื่อง และใน Pyrefly ก็มีแผนจะขยาย ประโยชน์ของการใช้ชนิดข้อมูล ให้สูงสุดสำหรับนักพัฒนา ไลบรารีต่าง ๆ และผู้เริ่มต้น
  • Meta วางแผนผลักดัน การยกระดับคุณภาพของชนิดข้อมูล ในระบบนิเวศ โดยอาศัยประสบการณ์และผลลัพธ์จากการใช้ชนิดข้อมูลในภาษาที่เป็นไดนามิก
  • แม้ตอนนี้ Pyrefly จะยังเป็นเวอร์ชันอัลฟา แต่ตั้งเป้าเปิดตัวอย่างเป็นทางการในช่วงฤดูร้อนนี้ พร้อมเดินหน้า แก้บั๊กและเพิ่มฟีเจอร์ อย่างต่อเนื่อง
  • ฟีดแบ็กจากชุมชนมีความสำคัญมาก และมีการเชิญชวนอย่างจริงจังให้ทดลองใช้ Pyrefly แล้วช่วย รายงานปัญหาและเสนอการปรับปรุง

การใช้งาน Pyrefly เวอร์ชันอัลฟาและข้อมูลชุมชน

  • กระบวนการพัฒนาและรายละเอียดเชิงเทคนิคของ Pyrefly ถูกเผยแพร่ผ่าน Meta Tech Podcast และการบรรยายในงาน PyCon US
  • มีการเผยแพร่ข่าวสารเพิ่มเติมผ่านหลายช่องทาง เช่น เว็บไซต์ที่เกี่ยวข้องกับ Meta Open Source, YouTube, Facebook, Threads, X และ LinkedIn

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

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

 
GN⁺ 2025-05-18
ความคิดเห็นจาก Hacker News
  • รู้สึกกังวลเล็กน้อยแทน "Python Language Tooling Team" ของ Meta เพราะ uv ได้รับความนิยมสูงมากจนมีลางว่าฝั่ง ty อาจจะชนะในสายนี้ ถ้าผิดพลาดก็อาจเกิดบรรยากาศแบบที่ทีมภายในถูกโอเพนซอร์สภายนอกกลบ จนผู้บริหารพูดทำนองว่า "ทีมนี้จำเป็นจริงหรือ? เปลี่ยนไปใช้โอเพนซอร์สเถอะ" เหมือนกรณี Atom หรือ Flow ซึ่งคิดว่าเป็นจุดที่ผู้จัดการ (Aaron Pollack?) ควรใส่ใจ
    • Kevin, กล่าวทักทายอย่างยินดีและเล่าว่าเคยทำงานกับ Flow มาก่อน ตอนนี้อยู่ในทีม Pyrefly อธิบายว่าครั้งนี้เลือกแนวทางที่ต่างจาก Flow และกำหนดให้โอเพนซอร์สกับการสร้างชุมชนเป็นลำดับความสำคัญอย่างชัดเจน ช่วงหลังมีความผันผวนมากเกี่ยวกับการลงทุนด้านโครงสร้างพื้นฐานของบริษัทต่าง ๆ แต่เชื่อว่าตอนนี้คือจุดเริ่มต้นของเส้นทางที่ถูกต้อง และขอขอบคุณสำหรับกำลังใจ
    • มีความเห็นว่า Meta ให้ความสำคัญอย่างมากกับการควบคุมโปรเจ็กต์โอเพนซอร์สด้านเครื่องมือพัฒนา โดยยกเรื่องในอดีตที่ผู้ดูแล git ชี้ปัญหาเกี่ยวกับการใช้ monorepo และปฏิเสธการปรับปรุงใน upstream จนมีการย้ายไปใช้ mercurial แทน ขณะที่ฝั่ง mercurial ยินดีรับ contribution เรื่องนี้อธิบายว่าความเปลี่ยนแปลงของเครื่องมือภายในเกิดขึ้นเร็วมาก การเป็นเจ้าของโปรเจ็กต์เองจึงสมเหตุสมผล
    • บอกว่าสิ่งที่ชอบที่สุดจาก Facebook คือ JSX (และอาจเป็นอย่างเดียวที่คิดว่าดี)
  • แนะนำตัวว่าทำงานอยู่ในทีม Pyrefly ของ Meta บอกว่า FAQ ครอบคลุมคำถามจำนวนมากแล้วจึงแนบลิงก์ให้อ้างอิง พร้อมแสดงความเป็นมิตรว่ายินดีตอบคำถามเพิ่มเติม และขอบคุณสำหรับความสนใจ
  • สังเกตว่าช่วงนี้มี Python type checker ที่เขียนด้วย Rust ปรากฏขึ้นสามเจ้า (Microsoft, Facebook, Astral) และ mypy เดิมก็ยังคงอยู่
    • มีการแก้ไขว่า type checker ของ Microsoft คือ Pyright ซึ่งเขียนด้วย Typescript แต่จากประสบการณ์ส่วนตัวก็ยังเร็วกว่า mypy
    • มีคำถามว่าทั้งหมดเป็น static type checker ใช่ไหม และมีการตอบว่าไม่มีตัวสำหรับ runtime
  • ให้ข้อมูลว่านี่คือการประกาศอย่างเป็นทางการ แต่จริง ๆ แล้ว Pyrefly ถูกพูดถึงไปเมื่อไม่กี่สัปดาห์ก่อนแล้ว ตอนนี้เปิดตัวในขั้น alpha และทีมกำลังโฟกัสกับการแก้บั๊กและพัฒนาฟีเจอร์ โดยตั้งเป้าจะถอดป้าย alpha ออกภายในฤดูร้อน ตามคำกล่าวอย่างเป็นทางการของทีม
  • โค้ด Rust ที่เขียนไว้ที่นี่เข้าใจง่ายมาก แต่ก็มีความกังวลกับแนวโน้มที่เครื่องมือ Python ช่วงนี้ถูกเขียนด้วย Rust ต่อเนื่อง และกลัวว่าจะกลายเป็นปัญหาอีกแบบของ N ภาษา หวังว่า Mojo อาจช่วยอะไรในจุดนี้ได้
    • มีคำอธิบายว่าใน ecosystem ของ Python เป็นเรื่องธรรมชาติที่จะใช้ Python กับงานที่ Python รับไหว และใช้ภาษาอย่าง Rust หรือ C กับงานที่ต้องการประสิทธิภาพสูง สุดท้ายแล้ว N=3 (Python, Rust, C) เพียงแต่หวังว่าในระยะยาว C ควรค่อย ๆ หายไปจากการเขียนโปรแกรมแอปพลิเคชัน แม้ความเป็นจริงคงต้องใช้เวลาอีกนาน และ Python เองก็อาจกลายเป็น legacy ได้ก่อน
  • รู้สึกยินดีที่มีการแนะนำวิธี integrate กับ Vim/Neovim พร้อมให้ลิงก์ที่เกี่ยวข้อง
  • สงสัยว่าทำไมการที่เขียนด้วย Rust ถึงถูกพูดเหมือนเป็นข้อดีใหญ่นัก เพราะคนส่วนใหญ่ไม่ได้รัน type checker บนระบบ embedded หรือบริการ mission-critical ให้ความรู้สึกคล้ายการบอกว่า "เขียนด้วย Erlang" งานที่ไม่ใช่โค้ดซึ่ง performance สำคัญมากควรเขียนด้วย Python มากกว่า เพื่อเปิดโอกาสให้ชุมชนเข้าร่วมและขยายตัวได้มากขึ้น จึงสงสัยว่าทำไมถึงยึดติดกับ Rust
    • มีการแชร์ประสบการณ์ใช้ Rust ว่าในมุมผู้ใช้ได้ทั้งความเร็วและความปลอดภัย ส่วนในมุมนักพัฒนาก็เอื้อต่อการมีส่วนร่วม คิดว่าเสน่ห์ของ Astral ก็อยู่ตรงการนำเครื่องมือที่สร้างบน Rust มาให้โลก Python แม้จะรู้ Python ดีกว่า Rust แต่กลับรู้สึกว่าการร่วมพัฒนาโปรเจ็กต์ Rust ง่ายกว่า และมองว่าเป้าหมายโดยรวมคือการย้ายเครื่องมือคุณภาพระดับ Rust มาสู่ Python
    • มองว่า LSP (Language Server Protocol) เป็นโค้ดที่ performance สำคัญมาก เพราะส่งผลโดยตรงต่อความตอบสนองของ IDE และ Rust ก็มีประสิทธิภาพทั้งด้าน CPU และหน่วยความจำ ถ้าเขียนด้วย OCaml, Reason, Haskell ฯลฯ ก็คงเร็วและมีประสิทธิภาพพอ แต่ฐานผู้ร่วมพัฒนาจะจำกัดมาก
    • พอค้นหา "[คำอธิบายเครื่องมือ] rust" ก็สามารถหา software ที่เร็วได้ง่าย ซึ่งน่าพอใจ และแชร์ประสบการณ์ว่าเครื่องมือที่ใช้ราว 95% เขียนด้วย Rust และส่วนใหญ่ก็น่าพอใจมาก
    • Rust ถูกใช้เหมือนคำย่อของ "เร็วแบบสังเกตได้ชัด" และย้ำว่าโอเพนซอร์ส Rust ก็ยังตรวจรีวิวได้
    • อธิบายว่า type checker ที่เขียนด้วย Python มีข้อจำกัดด้านประสิทธิภาพ เช่น linter อย่าง Pylint ที่เขียนด้วย Python อาจต้องตรวจทีละบรรทัดของโค้ดและใช้เวลามากกว่า 30 วินาที จึงยืนยันว่านี่คือพื้นที่ที่ performance สำคัญ
  • สงสัยเกี่ยวกับการเปลี่ยนจาก Pyre ไปเป็น Pyrefly และการ rewrite ใหม่ทั้งหมดด้วย Rust อยากรู้ว่ามีข้อดีหรือแรงจูงใจที่เป็นรูปธรรมอะไรบ้างจากการย้ายจากภาษาที่คนรู้จักน้อยกว่าไปสู่ Rust ที่กำลังเป็นกระแส
    • มีคำตอบว่าคำถามนี้อยู่ใน FAQ ของทีม และเมื่อมีประสบการณ์สะสมมากขึ้นก็อยากเล่าในบล็อกโพสต์ยาว ๆ พร้อมแนบลิงก์
  • มีความเห็นว่าโปรเจ็กต์นี้ดูเหมือนพยายามแก้หลายอย่างมากเกินไปในคราวเดียว
  • บอกว่าพอเห็น VS Code ก็หมดความสนใจ ไม่เข้าใจว่าทำไมผู้คนถึงคิดว่า VS Code เหมาะจะเป็น IDE สำหรับ Python ทั้งที่มี IDE จริงอย่าง PyCharm อยู่แล้ว จึงมองว่าไม่มีเหตุผลจะใช้ VS Code
    • มีการชี้ว่า pyrefly ไม่ได้ถูกผูกกับ vscode อย่างเดียว และขอให้เปิดรับว่าคนแต่ละคนมีความชอบต่างกัน pycharm เองก็ไม่ได้ดีกว่าอย่างเด็ดขาด สำหรับตน vscode สะดวกเรื่อง remote development และก็ไม่อยากไปโพสต์บนอินเทอร์เน็ตว่า pycharm แย่