เปรียบเทียบ Pyrefly และ Ty: ตัวตรวจสอบชนิดข้อมูล Python รุ่นใหม่ที่สร้างด้วย Rust

 (blog.edward-li.com)
3 คะแนน โดย GN⁺ 2025-05-28 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไม่นานมานี้มีการเปิดตัวตัวตรวจสอบชนิดข้อมูล Python ที่สร้างด้วย Rust สองตัว ได้แก่ Pyrefly ของ Meta และ Ty ของ Astral ซึ่งแสดงให้เห็นทั้ง ประสิทธิภาพที่เหนือกว่ามาก เมื่อเทียบกับ mypy และ pyright เดิม รวมถึง แนวทางพาราไดม์การทำ typing แบบใหม่
  • Pyrefly มุ่งไปที่ การอนุมานชนิดข้อมูลเชิงรุก และแนวทางโอเพนซอร์ส ขณะที่ Ty นำหลักการ “** gradual guarantee**” มาใช้ โดยให้ความสำคัญกับการลดการเกิด type error ให้มากที่สุด
  • แม้ทั้งสองเครื่องมือยังอยู่ใน เวอร์ชันอัลฟาระยะแรก แต่ผลเบนช์มาร์กจากหลายโปรเจ็กต์แสดงให้เห็นว่า Ty ทำความเร็วเฉลี่ยได้สูงกว่า
  • ในด้าน incremental analysis นั้น Pyrefly ใช้การแยกเพิ่มระดับโมดูล ส่วน Ty ให้การแยกเพิ่มแบบละเอียดถึงระดับฟังก์ชัน จึงมีความต่างทั้งด้านการใช้งานและโครงสร้าง
  • Ty นำเสนอระบบชนิดข้อมูลที่ล้ำหน้า เช่น intersection types และ negation types พร้อมทั้งมี ข้อความ error ที่เข้าใจง่ายและชัดเจนกว่า

แนะนำ Pyrefly และ Ty

  • Pyrefly และ Ty เป็นตัวตรวจสอบชนิดข้อมูล Python ที่พัฒนาด้วย Rust
  • Pyrefly พัฒนาโดย Meta (ชื่อเดิม Facebook) และเข้ามาแทนที่ Pyre ที่สร้างด้วย OCaml
  • Ty พัฒนาโดย Astral ซึ่งเป็นที่รู้จักจากเครื่องมือ Python อย่าง uv และ ruff
  • ทั้งสองโปรเจ็กต์เปิดเป็นโอเพนซอร์สแล้ว แต่ยังอยู่ใน ขั้นอัลฟาก่อนเปิดตัวอย่างเป็นทางการ
  • ทั้งสองทีมได้นำเสนอวิสัยทัศน์ เป้าหมาย และแนวทางของตนในงาน PyCon 2025 Typing Summit

จุดเหมือนกัน

  • ทั้งคู่พัฒนาด้วย Rust และรองรับ incremental checking
  • ใช้ ruff ในการ parse AST ของโค้ด Python
  • เชื่อมต่อกับสภาพแวดล้อมการพัฒนาได้ดี ทั้งการตรวจชนิดข้อมูลผ่าน command line และการทำงานร่วมกับ LSP/IDE

ความแตกต่าง 1: ความเร็ว

เบนช์มาร์ก PyTorch

  • Ty เร็วกว่า Pyrefly ราว 2~3 เท่า และทั้งคู่ก็เร็วกว่า mypy กับ pyright เดิมประมาณ 10~20 เท่า
  • Pyrefly ตั้งเป้าปรับปรุงประสิทธิภาพให้เร็วกว่า Pyre 35 เท่า และเร็วกว่า mypy/pyright 14 เท่า
  • Ty ถูกออกแบบมาโดยมีเป้าหมายให้เร็วกว่า type checker รุ่นปัจจุบัน 1–2 หลัก

เบนช์มาร์ก Django

  • Ty เร็วที่สุด โดยมี Pyrefly ตามมาเป็นอันดับถัดไป
  • Pyright ให้ผลลัพธ์ที่ช้ากว่าอย่างชัดเจน

เบนช์มาร์ก repository ของ mypy

  • ได้ผลลัพธ์คล้ายกัน โดย Ty เร็วที่สุด และ Pyrefly ตามหลังมาแบบต่างกันไม่มาก
  • mypy และ pyright ใช้เวลาประมวลผลช้ากว่าอย่างเห็นได้ชัด

ความแตกต่าง 2: เป้าหมายด้าน typing

Pyrefly

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

Ty

  • ใช้หลัก Gradual guarantee
  • ออกแบบมาเพื่อไม่ให้เกิด type error เมื่อเอาชนิดข้อมูลแบบ explicit ออกจากโค้ดที่ทำงานได้อยู่แล้ว
  • ไม่ทำให้เกิด error เพียงเพราะไม่มี type annotation และจะขอ annotation เพิ่มเมื่อจำเป็นเท่านั้น
  • ตัวอย่างเช่น ต่อให้กำหนดค่าให้ฟิลด์ที่ไม่มี explicit type ก็จะไม่เกิด type error แต่จะจัดการเป็น 'Unknown | None' เป็นต้น

ความแตกต่าง 3: วิธีทำ incremental analysis

  • Pyrefly: วิเคราะห์ใหม่เฉพาะไฟล์ (โมดูล) ที่เปลี่ยนและโมดูลที่พึ่งพาอยู่เท่านั้น (incremental ระดับโมดูล)
  • Ty: ใช้เฟรมเวิร์ก Salsa ของ Rust เพื่อทำ incremental แบบละเอียดถึง ระดับฟังก์ชัน
  • ฝั่งหนึ่งมองว่าระดับโมดูลก็เร็วเพียงพอแล้ว ขณะที่อีกฝั่งเลือกระดับฟังก์ชัน แม้อาจทำให้ codebase ซับซ้อนขึ้น (เป็นความต่างด้านกลยุทธ์ของแต่ละเครื่องมือ)

ความแตกต่าง 4: ฟีเจอร์ (ระบบชนิดข้อมูลและการรองรับ)

จุดเด่นของ Pyrefly

  • การอนุมานชนิดข้อมูลแบบ implicit ทำได้ทรงพลังมาก
  • แม้ไม่มี explicit type ก็ยังวิเคราะห์ชนิดข้อมูลที่ซับซ้อน เช่น ค่าที่คืนจากฟังก์ชัน, dictionary, list และตรวจจับ error ได้
  • ออกแบบโดยให้ความสำคัญกับ ปัญหา typing ที่ซับซ้อน เช่น generic, overload และ wildcard import
  • มีความแม่นยำในการอนุมาน generic type สูงกว่า Ty

จุดพิเศษของ Ty

  • ด้วย “gradual guarantee” จึงยอมให้ชนิดข้อมูลเปลี่ยนได้อย่างอิสระเมื่อไม่มี explicit type
  • รองรับระบบชนิดข้อมูลที่ล้ำหน้า เช่น intersection types และ negation types
  • ข้อความ error ถูกออกแบบมาให้ชัดเจนและเข้าใจง่ายมาก
  • อนุญาตให้กำหนดชนิดข้อมูลหลากหลายแบบลงใน list ฯลฯ ได้อย่างอิสระ และนำค่า Unknown เข้ามาเป็นส่วนหนึ่งของระบบชนิดข้อมูล

ข้อจำกัด / สถานะอัลฟา

  • ทั้งสองผลิตภัณฑ์ยังอยู่ใน ขั้นอัลฟา ทำให้การอนุมานชนิดข้อมูลหรือบางฟีเจอร์ยังไม่สมบูรณ์
  • ตัวอย่างเช่น การอนุมานชนิดข้อมูลของ list ใน Ty บางกรณียังไม่สมบูรณ์นัก

เปรียบเทียบฟีเจอร์เชิงลึก

การอนุมานชนิดข้อมูลแบบ implicit

  • Pyrefly อนุมานชนิดข้อมูลของค่าที่คืนกลับและคอลเลกชันได้อย่างกระตือรือร้น พร้อมแสดง revealed type และ error อย่างชัดเจน
  • Ty จะคืนค่าเป็น Unknown หรือ @Todo เมื่อ inference ยังไม่เพียงพอ

Generic

  • ทั้ง Pyrefly และ Ty จัดการปัญหา generic type ทั่วไปได้ดี
  • Pyrefly เหนือกว่าในการตีความชนิดข้อมูลของ instance ที่ถูกสร้างขึ้นโดยไม่มี type parameter
  • แต่ทั้งสอง checker ยังดูด้อยกว่า mypy และ pyright ในประเด็น covariance/contravariance

ข้อความ error

  • Ty ให้ความสำคัญกับ ข้อความ error ที่กระชับและอ่านง่าย
  • เมื่อเทียบกับ Pyrefly, mypy และ pyright แล้ว ข้อความของ Ty เข้าใจได้ง่ายกว่าในทันที

Intersection / Negation types

  • มีเพียง Ty เท่านั้นที่รองรับ intersection types (&) และ negation types (~) เพื่อจัดการการคำนวณชนิดข้อมูลที่ซับซ้อนแบบด้านล่าง

    • ตัวอย่าง: ในชนิดข้อมูล WithX | Other หากมีแอตทริบิวต์ x อยู่ Ty จะทำ branching ไปเป็น WithX โดยอัตโนมัติ
    • ตัวอย่าง: หากไม่ใช่ subclass เฉพาะตัวหนึ่ง ก็จะตีความชนิดข้อมูลเป็น MyClass & ~MySubclass

  • intersection และ negation types ลักษณะนี้ถือเป็นฟีเจอร์ที่ก้าวหน้ามากในเชิงทฤษฎีชนิดข้อมูล

ตัวอย่างขั้นสูงอื่น ๆ

  • Ty สามารถนำระบบชนิดข้อมูลไปใช้กับการคำนวณซับซ้อน เช่น สมการไดโอแฟนไทน์ ได้ด้วย
  • ชุดทดสอบเขียนอยู่ในเอกสาร Markdown (อ้างอิง: mdtest resource ของ Astral ruff)

บทสรุปและแนวโน้ม

  • ตอนนี้ ecosystem ของ Python มี type checker แบบใหม่ที่ทั้งเร็วอย่างมากและมีแนวคิดใหม่ ปรากฏขึ้นแล้ว
  • Ty เลือกใช้กลยุทธ์หลักเป็น ความปลอดภัยของชนิดข้อมูลแบบค่อยเป็นค่อยไป ส่วน Pyrefly เน้น การอนุมานชนิดข้อมูลเชิงรุก
  • ทั้งสองเครื่องมือยังอยู่ในช่วงเริ่มต้น จึงยังมีโอกาสสูงที่ฟีเจอร์จะค่อย ๆ บรรจบกันหรือพัฒนาไปอีกมาก
  • สามารถลองใช้งานได้จากเว็บไซต์ทางการ และยังมีปลั๊กอินสำหรับเอดิเตอร์หลักอย่าง VSCode และ Cursor ให้ใช้งาน
  • ยังมีข่าวลือว่าในอนาคต Google อาจโอเพนซอร์ส type checker ที่สร้างด้วย Go เช่นกัน ทำให้วงการการวิเคราะห์ชนิดข้อมูลของ Python น่าจะยิ่งหลากหลายขึ้น

การใช้งาน / อ้างอิง

  • Pyrefly: pyrefly.org/sandbox
  • Ty: play.ty.dev
  • Ty ของ Astral ใช้การทดสอบแบบอิง Markdown (ดูรายละเอียดเส้นทางได้จาก mdtest ใน repo ของ ruff)
  • มีทั้งเอกสารทางการ, ปลั๊กอินเอดิเตอร์ และคำสั่งติดตั้งแพ็กเกจให้พร้อมใช้งาน

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

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

 
q8840 2025-05-29

ดูเหมือนว่า ty จะถือว่าเป็น unknown เสมอถ้าฟังก์ชันที่ใช้งานไม่ได้ระบุ return type ไว้ และจะตรวจให้ก็ต่อเมื่อบันทึกเท่านั้น
ส่วน pyrefly ถึงไม่ระบุก็ยังอนุมานให้ได้ และตรวจให้ได้ระหว่างพิมพ์ด้วย
 
GN⁺ 2025-05-28
ความเห็นจาก Hacker News

  • ในฐานะผู้พัฒนา ty เน้นว่ายินดีที่ ty และ pyrefly ได้รับความสนใจมากขึ้น แต่ก็ขอย้ำอีกครั้งว่าทั้งสองโปรเจ็กต์ยังไม่เสร็จสมบูรณ์ทั้งหมด ยังมีตัวอย่างที่เกิดจากฟีเจอร์ที่ยังไม่ถูกพัฒนาอยู่ ดังนั้นเวลารู้สึกว่า “นี่มันแปลกนะ” ก็อาจเป็นเพราะส่วนนั้นยังทำไม่เสร็จก็ได้ และต้องเข้าใจด้วยว่า Python เป็นภาษาที่ใหญ่มากและหลากหลายมาก

    • มีความเห็นว่าชอบวิธีทดสอบสไตล์ markdown ของ ty มาก เพราะตัวทดสอบทำหน้าที่เป็นเอกสารไปด้วย เป็นไอเดียที่ยอดเยี่ยมมาก และสงสัยว่าแนวคิดนี้ได้แรงบันดาลใจจากตัวอย่างโค้ดในเอกสารของ Rust หรือไม่

    • ขำกับการใช้ @TODO เพื่อทำเครื่องหมายส่วนที่เปิดเผยชนิดข้อมูล แต่พอคิดดูแล้วก็รู้สึกว่าเป็นลูกเล่นที่ฉลาดและมีประโยชน์มาก

    • ในฐานะคนที่มีประสบการณ์กับ TypeScript มองว่าน่าสนใจกับความพยายามหลากหลายด้าน เช่น type inference, type narrowing และพฤติกรรมที่ต่างกันไปของตัวตรวจสอบชนิดข้อมูลแต่ละตัวของ Python ยังคงรู้สึกว่าจำเป็นต้องมี type checker ที่ทั้งเร็วและเชื่อถือได้ และ Python ดูจะตามหลังมากในด้านนี้ คิดว่า type checker ควรช่วยเพิ่มทั้งผลิตภาพและความน่าเชื่อถือของโค้ด จึงเอาใจช่วยโปรเจ็กต์เหล่านี้

    • จากมุมมองของนักพัฒนา Rust มีคำถามเรื่อง “ภาษา scripting สำหรับ Rust” ว่ามีชุมชนหรือเครือข่ายที่กำลังศึกษาภาษาซึ่งมีไวยากรณ์เข้ากับ Rust ได้ดี สามารถ import ชนิดข้อมูลของ Rust ได้แบบ native และคอมไพล์/ทำ hot reload ได้รวดเร็วหรือไม่ หรือ Python อาจทำหน้าที่นี้แทนได้แม้ไวยากรณ์จะแตกต่างกันก็ได้ พร้อมแนบลิงก์ที่เกี่ยวข้อง https://news.ycombinator.com/item?id=44050222

  • ความเห็นจากคนนอกที่ไม่ได้มีประสบการณ์กับ Python มากนักว่า ถ้าสนใจการใช้ type hint ควรลองดูโพสต์ใน Reddit https://www.reddit.com/r/Python/comments/10zdidm/why_type_hinting_sucks/ แต่ก็ไม่ควรจริงจังกับโพสต์นั้นมากเกินไป โดยเน้นว่าต่อให้มีเครื่องมือด้าน type ที่ดีแค่ไหน “แนวปฏิบัติที่ดี” ก็ต้องมาก่อน ยกตัวอย่างว่าถ้าจะให้เกิดการใช้งานอย่างสม่ำเสมอและมี strict type check ได้ใน codebase ขนาดใหญ่อย่าง Django หรือ Meta ก็ต้องทำให้นักพัฒนายึดตามธรรมเนียมที่แนะนำ Python ก็เหมือน C++ ตรงที่มีฟีเจอร์มากเกินไปและมี runtime ที่ผ่อนปรนมาก จนสุดท้ายต้องเลือกใช้เพียงบางส่วนอย่างจำกัดเพื่อให้ดูแลง่าย แต่ส่วนที่จำกัดนั้นก็อาจต่างกันไปตามคนและวัตถุประสงค์ พร้อมเปรียบเทียบกับกรณีที่นักพัฒนา Rust ปะทะกับนักพัฒนา Linux kernel เพราะระบบ type ที่เข้มงวดกว่า

    • ในคอมเมนต์ยอดนิยมของโพสต์ Reddit ดังกล่าว มีการปัดประเด็นด้วยแนวคิดประมาณว่า “ก็ใช้ Any สิ งั้นการถกเถียงก็ไม่มีความหมาย” แต่จากกรณีจริง ถ้ามีการประกาศชนิดข้อมูลที่ชัดเจนกว่านี้ ก็จะช่วยป้องกันข้อผิดพลาดล่วงหน้าจากการเปลี่ยนแปลงของฟังก์ชันในไลบรารีหรือค่าป้อนเข้าที่ไม่คาดคิดได้ จึงมีข้อยืนยันอย่างหนักแน่นว่าถ้าอยากให้โค้ด Python ดูแลรักษาได้และเชื่อถือได้ การตรวจสอบชนิดข้อมูลเป็นสิ่งจำเป็น

    • สรุปว่าการทุ่มเวลาและแรงไปกับ type check ของ Python มากเกินไป อาจสู้ย้ายไปใช้ภาษาที่มี static typing และเหมาะสมกว่าโดยตรง แล้วใช้ Python เฉพาะส่วนที่จำเป็นผ่าน interop layer จะดีกว่า แม้จะไม่ใช่ทางเลือกที่ทำได้เสมอไป แต่ก็รู้สึกว่าเสียเวลากับการพยายามฝืน Python มากเกินไป

    • วิจารณ์ว่าความสามารถอันทรงพลังและซับซ้อนของ Python (เช่น meta class, descriptor, การใช้ __call__, object.__new__, name mangling, self.__dict__) มีความเป็นเวทมนตร์มากเกินไปจนทำให้ความอ่านง่ายของโค้ดลดลงมาก และประกาศว่าตัวเองจะไม่ใช้ฟีเจอร์พวกนี้

    • สงสัยว่าการออกความเห็นทั้งที่ไม่ได้ใช้งานภาษาจริง ๆ นั้นมาจากไหน เพราะนักพัฒนา Python เข้าใจภาษาอย่างลึกซึ้งผ่านการใช้งานจริงอยู่แล้ว จึงแปลกใจกับการที่คนไม่ใช้ภาษามาวิจารณ์ภาษาโดยอ้างเหตุผลจากภายนอก และชี้ให้เห็นบรรยากาศการถกเถียงด้วยตัวอย่างที่ถูกสร้างขึ้นมาแบบฝืน ๆ

    • ในฐานะคนที่ใช้ Python มาหลายปี ยืนยันว่าความผิดพลาดใหญ่ที่สุดคือการไม่ใช้ type hint และ type checker เลยตั้งแต่แรก

  • สนใจแนวคิด “gradual guarantee” ของ ty คือแม้จะลบ type annotation ออกหนึ่งตัวก็ไม่ควรทำให้เกิด type error ซึ่งฟังดูน่าสนใจ และคิดว่าน่าจะเป็นแนวทางที่เหมาะกับ Python ที่มีโค้ดแบบ dynamic จำนวนมากที่สุด

    • ย้อนความว่าระบบ gradual typing คือโครงสร้างที่แม้จะมี “any” (ชนิดที่ยังไม่แน่ชัด) อยู่ตรงไหนในโค้ดก็อาจไม่มีคำเตือนเลย ทำให้แม้แต่โค้ดสำคัญก็ไม่ได้รับการคุ้มครองด้วย type safety อย่างแท้จริง ประสบการณ์กับ mypy ก็พบว่านี่เป็นปัญหาร้ายแรง และรู้สึกว่าควรมีความสามารถในการประกาศว่า “ไฟล์นี้จะถูกตรวจชนิดข้อมูลแบบ static อย่างสมบูรณ์” มองว่า “gradual” typing ค่อนข้างใกล้เคียงกับ anti-pattern เสียด้วยซ้ำ และคำว่า “soft typing” อาจเหมาะกว่า

    • มองว่าใน codebase เดิมที่มีอยู่ก่อนแล้ว ไม่มีทางเลือกอื่นนอกจาก gradual typing จริง ๆ จากประสบการณ์ที่เคยใส่ type hint ให้กับ legacy Python codebase หลายแห่งด้วย mypy พบว่า “การ opt-in ระดับโมดูล” สมเหตุสมผลที่สุด ถ้า pyrefly ไม่รองรับเรื่องนี้ก็น่าจะมีข้อจำกัดด้านการใช้งานจริง อย่างไรก็ตาม ถ้ามองจากมุมของการสร้างโค้ดด้วย llm (โมเดลภาษาขนาดใหญ่) type checker ที่เร็วมากและเข้มงวดก็ยังมีประโยชน์

    • คล้ายกับช่วงแรกของการนำ Typescript มาใช้ คือให้ความสำคัญกับการ onboarding แบบนุ่มนวลสำหรับโปรเจ็กต์ขนาดใหญ่ที่มีอยู่เดิม แล้วค่อย ๆ เปิด noImplicitAny หรือ strict เป็นรายโมดูล เพื่อเปลี่ยนไปสู่สภาพแวดล้อมที่ตรวจสอบชนิดข้อมูลได้เข้มแข็งในที่สุด

    • แม้ในฐานะโปรแกรมเมอร์ Rust ก็ยังคิดว่า “gradual guarantee” เป็นแนวคิดที่สมเหตุสมผลที่สุด

    • ระบุว่าการรองรับ gradual typing แบบนี้ไม่ดึงดูดตัวเองเท่าไร เพราะเดิมทีระบบ dynamic type ของ Python ก็ดูไม่น่าไว้วางใจอยู่แล้ว และครึ่งหนึ่งของเหตุผลที่เพิ่ม type annotation ก็เพื่อควบคุมพฤติกรรมที่ผิดพลาดเหล่านั้น จึงอยากได้ตัวเลือกอย่าง no-implicit-any หรือ strict mode อย่างยิ่ง

  • เครื่องมือของ Astral นำพลังสดใหม่มาสู่ ecosystem ของ Python ก็จริง แต่ก็มีคำถามเรื่อง “มุมมองระยะยาว” ว่าต่อไปจะถูกรวมเข้า Python โดยตรงไหม จะหายไปในอีก 5 ปีหรือไม่ หรือจะกลายเป็นการ rug pull แบบสมัครสมาชิกหรือเปล่า

    • มีความเป็นไปได้สูงว่า Astral อาจใช้ Business Source License เพื่อผลักดันให้การ deploy production ที่ใช้เครื่องมือของ Astral ต้องพึ่งการสมัครใช้งานระดับองค์กรหรือรูปแบบคล้ายกัน แม้ผลิตภัณฑ์ปัจจุบันจะยังไม่ตรงจุดนั้นนัก แต่จากมุมของการลงทุนแบบ venture capital ก็ดูมีแนวโน้มจะไปในทิศทางนี้

    • ในประกาศอย่างเป็นทางการ Astral ระบุชัดว่าจะขายบริการหลากหลายอย่างบนเครื่องมือเหล่านี้ พร้อมลิงก์อ้างอิง https://astral.sh/blog/announcing-astral-the-company-behind-ruff

    • จริง ๆ แล้วความกังวลแบบนี้ไม่ได้ใช้ได้กับ Astral เท่านั้น แต่ใช้ได้กับทุกโปรเจ็กต์ และโดยเฉพาะ tooling จาก Facebook ก็มีความเสี่ยงสูงที่จะถูกปล่อยทิ้งไม่ดูแลเมื่อเวลาผ่านไป สุดท้ายผู้ใช้ก็ต้องยอมรับความเสี่ยงด้วยตัวเองเสมอ

    • อ้างความเห็นของผู้ใช้รายหนึ่งใน reddit ว่าโมเดลพื้นฐานของ VC ท้ายที่สุดคือหวังให้ถูก FAANG เข้าซื้อ หรือขยายให้ใหญ่พอจะไปสู่การ “acqui-hire” และ Astral ก็อาจลงเอยด้วยสถานการณ์แบบถูกควบรวมแล้วคนเก่งย้ายเข้าไปทำงาน เป็นต้น

    • มีข่าวลือว่าเมื่อไม่นานมานี้ Astral กำลังเตรียมเครื่องมือสำหรับองค์กรขนาดใหญ่ เช่น private package registry แบบโฮสต์ให้

  • ในตัวอย่าง “my_list = [1, 2, 3]” นั้น mypy, pyrefly และ pyright มองว่า my_list.append("foo") เป็น type error แต่มีเพียง ty ที่ยอมให้ผ่านได้โดยไม่ต้องประกาศอะไรเพิ่มเติม จึงมีข้อโต้แย้งว่าในงานจริงนั้นการใช้ list ที่มีชนิดเดียวกันตลอดเป็นเรื่องปกติ ดังนั้น type checker ก็ควรตั้งต้นจากสมมติฐานนี้ และไม่ควรทำให้การตรวจชนิดข้อมูลอ่อนแอลงเพียงเพราะ Python อนุญาต พร้อมวิจารณ์แรงว่าเหมือนเป็นนโยบายที่ออกแบบมาสำหรับโค้ดของมือใหม่มากเกินไป

    • ผู้พัฒนา ty อธิบายว่า “ตอนนี้ type inference ของ list literal ยังไม่เสร็จสมบูรณ์” ปัจจุบันยังใช้เพียง list[Unknown] ซึ่ง Unknown เป็น gradual type คล้าย Any จึงทำให้ append อะไรก็ได้ทั้งหมด มีแผนจะทำ inference ให้ละเอียดขึ้นในอนาคต และแนบลิงก์ issue ที่เกี่ยวข้อง https://github.com/astral-sh/ty/issues/168

    • มีความเห็นว่านี่ไม่ใช่การ optimize เพื่อผู้เริ่มต้น แต่เป็นสิ่งที่เลี่ยงไม่ได้เพื่อให้เข้ากันได้กับ legacy code เพราะถ้าจะนำ type checker เข้าไปใช้กับโค้ดจำนวนมากที่ยังไม่มี type ก็ต้องทำให้โค้ดเดิมทำงานได้ใกล้เคียงเดิมที่สุดเพื่อลดภาระ

    • มีข้อโต้แย้งว่า “การจะสร้าง tooling โดยเมินสิ่งที่ Python อนุญาต แล้วใช้ความเห็นส่วนตัวเป็นหลักนั้นฟังไม่ค่อยขึ้น”

    • มีการชี้ว่าปัญหาของแนวทาง pyrefly คือ “นำไปใช้ทั้งชุดกับ codebase ขนาดใหญ่ที่ไม่มี type ได้ยาก” เพราะต้องแก้โค้ดทีละจุด และถ้าในองค์กรไม่มีฉันทามติเรื่องงานนี้ก็ยิ่งทำได้ยาก เหมาะกับที่อย่าง Meta ที่บังคับภายในได้มากกว่า แต่ถ้าคิดถึงการนำมาใช้แบบค่อยเป็นค่อยไป แนวทางที่ผ่อนปรนกว่าอย่าง ty ก็ดูสมจริงกว่า ขณะเดียวกันส่วนตัวก็ยังชอบเครื่องมือที่เตือนเรื่อง mixed type มากกว่าเช่นกัน

    • มีความเห็นว่า “ถ้าเป็นโค้ด Python ที่รันได้จริง ก็ควรจะไม่เกิด type error เว้นแต่จะมีการจำกัดชนิดไว้อย่างชัดเจน” และถ้าต้องการ static subset ที่เข้มงวดกว่านี้ ก็ควรเพิ่ม type annotation ด้วยตัวเอง

  • มีผู้มีประสบการณ์เห็นว่าแนวทางของ Pyrefly ที่มุ่งไปทาง type inference ที่เข้มแข็งกว่านั้น ทำให้ในโค้ดขนาดใหญ่ที่ต้องการ type safety จริง จำนวน annotation ที่ต้องเขียนลดลงมาก แม้จะเริ่มต้นใช้งานยากกว่าแต่ระยะยาวมีประสิทธิภาพกว่า และมองว่า ty ในทางปฏิบัติก็แทบจะเป็นสถานะที่ปิด noImplicitAny ไว้

  • มีความคาดหวังอยากได้ type checker ที่รองรับการผสานกับ notebook (live coding) อย่างจริงจัง เพราะการตรวจแบบ static เพื่อจับข้อผิดพลาดก่อนรัน cell ยาว ๆ จะช่วยเพิ่มประสิทธิภาพอย่างมาก

    • มีการถามถึงประสบการณ์ใช้ Jupyter notebook ใน VSCode และชี้ว่าการใช้ type checker อย่าง pylance กับโค้ดทดลองอาจกลายเป็นสิ่งรบกวนได้ด้วย

    • มีคำแนะนำให้ลองประสบการณ์ของ Language Server ใน VSCode ซึ่งให้ feedback ได้ทันทีทั้งสำหรับ notebook integration และ live coding โดยอธิบายว่าสามารถตอบโจทย์ความต้องการด้านการตรวจชนิดข้อมูลแบบ interactive ได้

  • มองว่าการออกแบบของ Pyrefly คล้ายแนวทาง type inference ของ Typescript มากกว่า จึงรู้สึกว่าสมเหตุสมผลกว่าสำหรับตัวเอง และประเมินว่าการนำมาใช้แบบ gradual ในระดับโมดูลคืออุดมคติ ถ้าลงไปถึงระดับฟังก์ชันจะยิบย่อยเกินไปและเกินความจำเป็น อีกทั้งในแง่ประสิทธิภาพก็คิดว่าระดับโมดูลเพียงพอแล้ว

  • แม้โปรเจ็กต์จะมีความเป็น dynamic สูง ก็ยังคิดว่าตัวเองน่าจะเลือกแนวทางที่มี type inference เข้มแข็งกว่าแบบ Pyrefly แม้จะมีความไม่สะดวกตามมาบ้างก็ตาม

  • ตอนนี้ใช้ basedpyright ในทั้ง IDE และสภาพแวดล้อม CI และโดยรวมพอใจกับความเสถียร ส่วน mypy ไม่ค่อยชอบเพราะแม้แต่งาน type ง่าย ๆ ก็ยังล้มเหลวบ่อย