ประกาศเปิดตัว ty รุ่นเบตา

 (astral.sh)
7 คะแนน โดย GN⁺ 2025-12-17 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ty ซึ่งเป็น ตัวตรวจสอบชนิดข้อมูลและภาษาเซิร์ฟเวอร์สำหรับ Python ความเร็วสูงมาก ที่เขียนด้วย Rust ได้เปิดตัวในเวอร์ชันเบตา
  • ออกแบบมาให้เป็นทางเลือกแทน mypy, Pyright, Pylance และให้ ประสิทธิภาพเร็วกว่า 10~60 เท่า
  • ใช้ สถาปัตยกรรมแบบ incremental โดยคำนวณใหม่เฉพาะส่วนที่จำเป็นเมื่อมีการแก้ไขโค้ด เพื่อเพิ่มความเร็วในการตอบสนองแบบเรียลไทม์ให้สูงสุด
  • ให้ความสำคัญกับ ความแม่นยำและการใช้งาน โดยรองรับความสามารถของระบบชนิดข้อมูลสมัยใหม่ เช่น intersection types, advanced type narrowing และ reachability analysis
  • Astral มีแผนพัฒนา ty ให้เป็นเครื่องมือพัฒนาหลักของ ecosystem Python ร่วมกับ Ruff และ uv

ภาพรวมของ ty

  • ty คือ ตัวตรวจสอบชนิดข้อมูลและภาษาเซิร์ฟเวอร์สำหรับ Python ที่ Astral พัฒนาขึ้นและสร้างด้วย Rust
    • ออกแบบมาให้เป็นทางเลือกที่เร็วกว่า mypy, Pyright, Pylance อย่างมาก
    • ปัจจุบันมีการใช้งานอยู่แล้วในหลายโปรเจกต์ภายในของ Astral และในช่วงเบตาก็แนะนำให้ผู้ใช้ภายนอกเริ่มใช้งานได้
  • Astral เป็นทีมที่สร้างเครื่องมือพัฒนาสมรรถนะสูงสำหรับ ecosystem Python และเป็นที่รู้จักจาก uv (ตัวจัดการแพ็กเกจ) และ Ruff (linter และ formatter)

ประสิทธิภาพและสถาปัตยกรรม

  • ty ถูกออกแบบด้วย โครงสร้างที่ยึดภาษาเซิร์ฟเวอร์เป็นศูนย์กลาง และใช้ แนวทางการประมวลผลแบบ incremental ที่รันใหม่เฉพาะงานที่จำเป็นเมื่อมีการแก้ไขไฟล์
    • ส่งผลให้การอัปเดตแบบเรียลไทม์ภายใน editor ทำได้รวดเร็วมาก
  • แม้รันโดยไม่มีแคช ก็ยัง เร็วกว่า mypy และ Pyright 10~60 เท่า
    • ตัวอย่าง: เมื่อแก้ไขไฟล์หลักใน repository ของ PyTorch ความเร็วในการคำนวณผลวินิจฉัยใหม่อยู่ที่ 4.7ms ซึ่งเร็วกว่า Pyright (386ms) 80 เท่า และเร็วกว่า Pyrefly (2.38 วินาที) 500 เท่า
  • แม้ในโปรเจกต์ขนาดใหญ่ เมื่อเป็น การอัปเดตแบบ incremental ก็ยังมีช่องว่างด้านประสิทธิภาพมากกว่าหลายสิบเท่า

ระบบชนิดข้อมูลและความแม่นยำ

  • ty รองรับ intersection types, advanced type narrowing, reachability analysis ตามชนิดข้อมูล เป็นต้น
    • ความสามารถเหล่านี้ช่วยให้ให้ ฟีดแบ็กด้านชนิดข้อมูลที่แม่นยำ และลดการแจ้งเตือนผิดพลาดที่ไม่จำเป็น (false positive)
  • เป้าหมายไม่ใช่แค่เพิ่มความเร็ว แต่คือการสร้าง ตัวตรวจสอบชนิดข้อมูลที่ปรับปรุงทั้งความแม่นยำและประสบการณ์ผู้ใช้

ระบบวินิจฉัย

  • ty มี ระบบวินิจฉัยขั้นสูง ที่ได้รับแรงบันดาลใจจาก ระบบข้อความข้อผิดพลาดของคอมไพเลอร์ Rust
    • ในข้อความวินิจฉัยเดียวสามารถแสดงบริบทจากหลายไฟล์ร่วมกัน เพื่อให้เห็นสาเหตุของปัญหาและแนวทางแก้ไขได้ชัดเจน
    • ตัวอย่าง: เมื่อมีการกำหนดค่าให้คีย์ของ dictionary ไม่ถูกต้อง ระบบจะแสดงทั้งตำแหน่งที่ชนิดข้อมูลไม่ตรงกันและตำแหน่งที่มีการประกาศไว้
  • เอาต์พุตการวินิจฉัยเป็นอินเทอร์เฟซหลักของ ty และถูกออกแบบให้ ทั้งมนุษย์และ AI เข้าใจได้ง่าย

ความสามารถของภาษาเซิร์ฟเวอร์

  • ty ใช้งานได้กับ editor ทุกตัวที่รองรับ LSP (Language Server Protocol) เช่น VS Code, Cursor
    • รองรับความสามารถของภาษาเซิร์ฟเวอร์สมัยใหม่ครบถ้วน เช่น Go to Definition, Rename Symbol, Autocomplete, Auto Import, Semantic Syntax Highlighting, Inlay Hints
  • ติดตั้งได้ผ่าน ส่วนขยายของ VS Code และสามารถติดตั้ง CLI ได้ด้วยคำสั่ง uv tool install ty@latest

แผนในอนาคต

  • เป้าหมายระยะสั้นหลังเบตาคือ เพิ่มเสถียรภาพและแก้ไขบั๊ก, ทำสเปกชนิดข้อมูลของ Python ให้สมบูรณ์, และ รองรับ Pydantic กับ Django
  • ในระยะยาวมีแผนขยาย ty ให้เป็น เอนจินฟีเจอร์เชิงความหมาย ของชุดเครื่องมือ Astral
    • เตรียมเพิ่มความสามารถอย่าง การลบโค้ดที่ตายแล้ว, ตรวจจับ dependency ที่ไม่ได้ใช้งาน, การวิเคราะห์การเข้าถึงช่องโหว่ความปลอดภัย (CVE), การ lint ที่รับรู้ชนิดข้อมูล
  • Astral ตั้งเป้าปรับปรุง ty อย่างต่อเนื่องเพื่อทำให้ Python เป็น ecosystem การเขียนโปรแกรมที่มีประสิทธิผลมากที่สุด

คำขอบคุณ

  • การพัฒนา ty มีผู้มีส่วนร่วมจากโอเพนซอร์สหลายสิบคน และเปิดเผยภายใต้ MIT License
  • บุคคลและทีมหลายรายจาก Salsa, Elixir, และ ชุมชน Python typing ได้ให้ความร่วมมือทางเทคนิคและแรงบันดาลใจ
  • ทีมหลักของ Astral พัฒนา ty บนพื้นฐานความเข้าใจอย่างลึกซึ้งเกี่ยวกับ ทฤษฎีชนิดข้อมูล, ความหมายของ Python runtime, และ รูปแบบการใช้งานใน ecosystem

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

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

 
iolothebard 2025-12-19

Astral เป็นสาย Python หรือสาย Rust กันแน่…
ช่าง Astral เสียจริง~
 
GN⁺ 2025-12-17
ความคิดเห็นจาก Hacker News

  • อยากให้เพิ่ม Ty เข้าไปในตารางเปรียบเทียบนี้
    พอดูตารางผลลัพธ์ Python typing conformanceแล้ว คิดว่าไม่ควรประเมินความสามารถของ Pyright ต่ำเกินไป
    ลองใช้ Ty (LSP) ใน Emacs อยู่พักหนึ่งแล้ว มันทำงานได้ค่อนข้างดีทีเดียว แต่มีจุดที่กวนใจนิดหน่อยคือตอนแสดงเมธอดซิกเนเจอร์ type annotation ของบางพารามิเตอร์ดู ยืดยาวเกินไป
    ถึงอย่างนั้นในระยะยาวก็ค่อนข้างคิดว่าน่าจะใช้ Ty ขอแสดงความยินดีกับการออกเบต้าครั้งแรก

    • การทำตามสเปกก็สำคัญ แต่ไม่แนะนำให้เลือก type checker จากเรื่องนั้น
      มันค่อนข้างห่างจากสิ่งที่ผู้ใช้จริงให้ความสำคัญ (ผมก็เป็นคนทำทั้งสเปกและเทสต์ร่วมกันใน Python Typing Council)
    • เราก็มีแผนจะเพิ่มเข้าไปในตารางนั้นเร็ว ๆ นี้เหมือนกัน กว่าจะไล่ตามระดับ conformance ของ Pyright ให้ทันคงต้องใช้เวลาอีกหน่อย แต่เป้าหมายคือทำให้ได้ก่อนออกตัวจริง
    • Pyright ก็ดีมาก แต่ BasedPyright เป็นเวอร์ชันที่ปรับปรุงต่อยอดจากมันอีกที
      ถึงอย่างนั้นผมก็เป็นผู้ใช้ uv ที่พอใจมาก และถ้า Ty เสถียรพอก็คิดว่าจะย้ายไปใช้
    • PR นี้ยังอยู่ในสถานะ WIP แต่ก็ทำให้ผมมีแรงจูงใจกลับมาทำ OSS contribution อีกครั้ง
    • Pyright นั้นดี แต่ ความเร็ว ช้า ความไวในการตอบสนองของ LSP ส่งผลต่อ UX มาก เลยอยากเห็นว่า Ty จะดีขึ้นได้แค่ไหน

  • Astral กำลังสร้างเครื่องมือที่ยอดเยี่ยม ก็หวังว่าจะเติบโตได้ดีโดยไม่ต้อง หารายได้แบบทำลายของเดิม

    • ผลิตภัณฑ์เชิงพาณิชย์ตัวแรกของ Astral คือ pyx หวังว่าจะประสบความสำเร็จและได้สร้างเครื่องมือโอเพนซอร์สเจ๋ง ๆ ต่อไป
    • งานที่ทำมาจนถึงตอนนี้ถือว่าแทบเป็น บริการสาธารณะ ให้กับชุมชน Python เลย
    • ทิศทางให้ความรู้สึกคล้าย bun
    • แต่ก็น่าเสียดายที่ชอบบอกว่าจะมาแทนเครื่องมือเดิมทั้งหมด ทั้งที่ในความเป็นจริงยังทำฟีเจอร์ได้ไม่ครบ
      สุดท้ายก็มีกรณีที่ต้องย้อนกลับไปใช้เครื่องมือเดิม สำหรับผม การตรวจ type ที่ถูกต้องแม่นยำ สำคัญกว่าความเร็ว

  • ขอบคุณทีม Astral เราใช้ Pydantic หนักมาก เลยตื่นเต้นที่บอกว่าจะมีการรองรับระดับ first-class ใน Ty เวอร์ชันทางการ
    ตอนนี้เรารันทั้ง Pyright และ Mypy ไปพร้อมกัน ซึ่งมันจับข้อผิดพลาดคนละแบบจนรู้สึกซ้ำซ้อน
    ตามตารางนี้บอกว่า Pyright เป็น superset แต่จากประสบการณ์จริงของผมไม่เป็นแบบนั้น
    นั่นเป็นการวิเคราะห์เมื่อ 2 ปีก่อน ตอนนี้อาจต่างออกไปก็ได้ อยากรู้ว่ามีกรณีที่รวมมาใช้ Pyright ตัวเดียวบนโค้ดเบสขนาดใหญ่หรือยัง

    • ผมเองก็เป็น ผู้ใช้ mypy ยุคแรก และเคยเอามาเทียบกับตอนที่ Pyright ถูกเพิ่มเข้าไปใน VS Code
      หลายครั้ง mypy อนุมานได้ยืดหยุ่นและแม่นยำกว่า ส่วน Pyright มี false positive เยอะจนผมเคยปิดมันไปเลย
      ทุกวันนี้ Pyright อาจพัฒนาไปมากแล้ว แต่ BasedPyright กลับยิ่งทำให้ทำงานได้น้อยลง
      ในชุมชนมีบรรยากาศชอบกด mypy ลงแล้วอวย Pyright กันมาก แต่ประสบการณ์ของผมค่อนข้างต่างออกไป
    • จะพูดอีกครั้งว่า เทสต์การทำตามสเปก ไม่ได้สะท้อนประสบการณ์ผู้ใช้จริง
      มันโฟกัสที่ semantic ของ annotation เป็นหลัก เลยไม่เหมาะจะใช้เป็นเกณฑ์เลือก type checker
      (ผมเองก็ทำทั้งสเปกและเทสต์นี้ใน Python Typing Council)

  • คิดว่าชื่อควรเป็น “ประกาศ Ty Beta Release” มากกว่า
    ผมชอบ Pyrefly มากกว่า Pyright แต่ช่วงนี้มีบั๊กจนต้องตรึงเวอร์ชันเก่าไว้เลยลำบาก
    พอลองติดตั้ง Ty ก็เจอข้อผิดพลาดเรื่องความเข้ากันได้ของเวอร์ชัน Cursor

    • ถ้ามีข้อความผิดพลาดเพิ่มเติม รบกวน เปิด issue ด้วย ผมใช้ส่วนขยาย Ty บน Cursor มาหลายสัปดาห์แล้วโดยไม่มีปัญหา เลยรีโปรดิวซ์ไม่ได้
    • (ผมคือเมนเทนเนอร์หลักของ Pyrefly) ถ้าแครชนั่นช่วยไปเปิดเป็น issue ใน รีโพซิทอรี Pyrefly ด้วยก็ดี

  • ยังไม่เข้าใจเลยว่าทำไมภาษาหนึ่งถึงยังมี type checker มากขนาดนี้
    คนทำไลบรารีต้องทดสอบกับทุกตัวเลยไหม หรือว่านักพัฒนาควรใช้เฉพาะไลบรารีที่รองรับ checker ที่ตัวเองเลือก?

    • Python เป็นภาษาแบบ duck typing + optional type annotation ก็เลยเลี่ยงไม่ได้ที่จะมีหลายแนวทางให้ทำออกมา
    • บางส่วนเกิดจากความต่างเรื่องขอบเขตของการอนุมานฝั่ง caller หรือ นโยบายการบังคับให้ระบุ type แบบ explicit
      ตรงขอบเขตของแพ็กเกจจำเป็นต้องมี type แบบ explicit แต่ในโค้ดภายในจะมีความกำกวมเยอะ
      โดยเฉพาะ Astral ตั้ง ประสิทธิภาพของ incremental processing เป็นเป้าหมายการออกแบบหลัก
    • ในทางปฏิบัติส่วนใหญ่ก็เทสต์กันตาม mypy เป็นหลัก ส่วน Pyright ก็กำลังมีอิทธิพลมากขึ้นเรื่อย ๆ เพราะเป็นส่วนขยายค่าเริ่มต้นของ VS Code
      ถ้าจำเป็นก็สามารถแจก type stub เองเพื่อให้เข้ากันได้

  • ชอบที่ Ty มีจุดยืนว่า “ไม่จำเป็นต้องเพิ่ม annotation เพื่อเอาใจ type checker”
    checker รุ่นก่อน ๆ ชอบมากวนด้วยคำเตือนจุกจิก แต่ Ty จับ ข้อผิดพลาดเชิงตรรกะ จริง ๆ ได้ดี

  • วันนี้เพิ่งรู้ว่า Ty ทำหน้าที่เป็น language server (LSP) ได้ด้วย
    แปลว่าใน Neovim หรือ VSCode มันอาจมาแทนทั้ง mypy และ Pyright ได้

  • อยากรู้ว่ารองรับ Django แค่ไหน Django มี โค้ดเชิง magic เยอะมากจน type checker จัดการยาก

    • Ty ยังไม่รองรับ Django และก็ยังไม่มี ระบบปลั๊กอิน
      ถ้าใช้ Django อยู่ ช่วงนี้น่าจะยังต้องใช้ mypy หรือ Pyright ต่อไปก่อน

  • ต่อให้ Ty ไม่เร็วมาก แต่แค่รองรับ intersection type (A & B) ก็ถือว่าน่าใช้แล้ว
    ดีใจที่ได้เห็นฟีเจอร์ที่หายไปจากระบบ type มาตรฐานของ Python

  • สงสัยว่าใน Ruby มีอะไรคล้าย uv ไหม ใน Python หรือ TypeScript ผมใช้ uv หรือ bun แต่ Ruby ยังดูตามหลังอยู่

    • มีเครื่องมือจัดการ Ruby ตัวใหม่ชื่อ Rv ซึ่งอาจเป็นตัวเลือกนั้นได้