ty बीटा रिलीज़ की घोषणा

 (astral.sh)
7 पॉइंट द्वारा GN⁺ 2025-12-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust में लिखा गया अत्यंत तेज़ Python type checker और language server ty अब बीटा वर्ज़न में जारी किया गया है
  • इसे mypy, Pyright, Pylance के विकल्प के रूप में डिज़ाइन किया गया है, और यह 10~60 गुना तेज़ प्रदर्शन देता है
  • Incremental architecture के ज़रिए, कोड बदलने पर केवल ज़रूरी हिस्सों की दोबारा गणना की जाती है, जिससे real-time response speed अधिकतम होती है
  • सटीकता और usability पर ज़ोर देते हुए यह intersection types, advanced type narrowing, reachability analysis जैसे आधुनिक type system features को सपोर्ट करता है
  • Astral की योजना है कि ty को Ruff, uv के साथ Python ecosystem के मुख्य development tools में विकसित किया जाए

ty का परिचय

  • ty Astral द्वारा विकसित Python type checker और language server है, जिसे Rust में implement किया गया है
    • इसे मौजूदा mypy, Pyright, Pylance की तुलना में कहीं अधिक तेज़ विकल्प के रूप में डिज़ाइन किया गया है
    • Astral के आंतरिक प्रोजेक्ट्स में इसका पहले से उपयोग हो रहा है, और बीटा चरण में इसे बाहरी उपयोगकर्ताओं के लिए भी अनुशंसित किया जा रहा है
  • Astral Python ecosystem के लिए high-performance development tools बनाने वाली टीम है, जो uv (package manager) और Ruff (linter और formatter) के लिए जानी जाती है

प्रदर्शन और आर्किटेक्चर

  • ty को language server-केंद्रित संरचना के साथ डिज़ाइन किया गया है, और फ़ाइल बदलने पर केवल आवश्यक computation फिर से चलाने वाली incremental processing approach अपनाई गई है
    • इसके कारण editor के भीतर real-time updates की गति बहुत तेज़ रहती है
  • cache के बिना चलाने पर भी यह mypy और Pyright से 10~60 गुना तेज़ है
    • उदाहरण: PyTorch repository की मुख्य फ़ाइलों में बदलाव होने पर diagnostics की पुनर्गणना गति 4.7ms रही, जो Pyright (386ms) से 80 गुना और Pyrefly (2.38 सेकंड) से 500 गुना तेज़ है
  • बड़े प्रोजेक्ट्स में भी incremental updates के दौरान प्रदर्शन का अंतर कई दर्जन गुना तक देखा गया

type system और सटीकता

  • ty intersection types, advanced type narrowing, type-आधारित reachability analysis आदि को सपोर्ट करता है
    • इन सुविधाओं के ज़रिए यह सटीक type feedback देता है और अनावश्यक false positives को कम करता है
  • लक्ष्य सिर्फ़ गति बढ़ाना नहीं, बल्कि ऐसा type checker बनाना है जो सटीकता और user experience दोनों को बेहतर करे

diagnostics system

  • ty में Rust compiler के error message system से प्रेरित उन्नत diagnostics system शामिल है
    • एक ही diagnostic message में कई फ़ाइलों के context को साथ दिखाकर समस्या के कारण और समाधान की दिशा को स्पष्ट किया जाता है
    • उदाहरण: गलत dictionary key assignment होने पर type mismatch की जगह और declaration की जगह दोनों दिखाई जाती हैं
  • diagnostics output ty का मुख्य interface है, और इसे इंसानों तथा AI दोनों के लिए आसानी से समझ आने वाली संरचना में डिज़ाइन किया गया है

language server features

  • ty को VS Code, Cursor जैसे LSP(Language Server Protocol) सपोर्ट करने वाले सभी editors में इस्तेमाल किया जा सकता है
    • Go to Definition, Rename Symbol, autocomplete, auto import, semantic syntax highlighting, inlay hints जैसी सभी आधुनिक language server capabilities उपलब्ध हैं
  • इसे VS Code extension के माध्यम से install किया जा सकता है, और CLI installation के लिए uv tool install ty@latest कमांड भी उपलब्ध है

आगे की योजना

  • बीटा के बाद अल्पकालिक लक्ष्य हैं स्थिरता मज़बूत करना और bug fixes, Python type specification को पूरा करना, Pydantic और Django support
  • दीर्घकाल में ty को Astral toolchain के semantic feature engine के रूप में विस्तारित किया जाएगा
    • dead code removal, unused dependency detection, security vulnerability (CVE) reachability analysis, type-aware linting जैसी सुविधाएँ योजनाबद्ध हैं
  • Astral का लक्ष्य ty को लगातार बेहतर बनाकर Python को सबसे अधिक productive programming ecosystem बनाना है

आभार

  • ty के विकास में दर्जनों open source contributors ने भाग लिया, और इसे MIT license के तहत जारी किया गया है
  • Salsa, Elixir, Python typing community के कई व्यक्तियों और टीमों ने तकनीकी सहयोग और प्रेरणा दी
  • Astral की core team ने type theory, Python runtime semantics, ecosystem usage patterns की गहरी समझ के आधार पर ty का विकास किया

संबंधित पढ़ाई

2 टिप्पणियां

 
iolothebard 2025-12-19

Astral Python-प्रेमी है या Rust-प्रेमी…
काफ़ी astral-सा लग रहा है~
 
GN⁺ 2025-12-17
Hacker News की राय

  • अच्छा होगा अगर इस तुलना तालिका में Ty भी जोड़ा जाए
    Python typing conformance परिणाम तालिका को देखकर लगता है कि Pyright की क्षमता को कम करके नहीं आंकना चाहिए
    मैंने Emacs में Ty(LSP) को थोड़ी देर इस्तेमाल करके देखा, और यह काफ़ी अच्छी तरह काम करता है। बस, जब method signatures दिखते हैं तो कुछ parameters की type annotations थोड़ी ज़्यादा लंबी-चौड़ी लगती हैं, जो थोड़ा खटकता है
    फिर भी, लंबे समय में Ty इस्तेमाल करने की संभावना ज़्यादा लगती है। पहले beta release के लिए बधाई

    • spec compliance महत्वपूर्ण है, लेकिन उसी के आधार पर type checker चुनने की सलाह नहीं दूँगा
      यह उन चीज़ों से काफ़ी दूर है जिन्हें असली उपयोगकर्ता महत्वपूर्ण मानते हैं। (मैंने Python Typing Council में spec और tests दोनों बनाने पर काम किया है)
    • हम भी जल्द ही उस तालिका में जुड़ने वाले हैं। conformance के मामले में Pyright के स्तर तक पहुँचने में थोड़ा समय लगेगा, लेकिन official release से पहले वही लक्ष्य है
    • Pyright भी शानदार है, लेकिन BasedPyright उसका और बेहतर किया हुआ संस्करण है
      फिर भी, मैं uv का संतुष्ट उपयोगकर्ता हूँ, इसलिए जब Ty काफ़ी स्थिर हो जाएगा तो उस पर जाने का सोच रहा हूँ
    • यह PR अभी WIP स्थिति में है, लेकिन इसने मुझे फिर से OSS contribution शुरू करने की प्रेरणा दी है
    • Pyright अच्छा है, लेकिन speed धीमी है। LSP की responsiveness का UX पर बड़ा असर पड़ता है, इसलिए Ty ने इसमें कितना सुधार किया है यह देखने की उत्सुकता है

  • Astral शानदार tools बना रहा है, इसलिए उम्मीद है कि वह आक्रामक monetization के बिना अच्छी तरह बढ़े

    • Astral का पहला commercial product pyx है। उम्मीद है यह सफल हो ताकि वे ऐसे ही शानदार open source tools बनाते रहें
    • अब तक का उनका काम Python community के लिए लगभग public service जैसा लगता है
    • दिशा कुछ हद तक bun जैसी लगती है
    • लेकिन यह थोड़ा अफ़सोसजनक है कि वे मौजूदा tools को पूरी तरह replace करने का दावा करते हैं, जबकि व्यवहार में सारी features अभी implement नहीं हुई हैं
      नतीजा यह होता है कि कभी-कभी वापस पुराने tools पर लौटना पड़ता है। मेरे लिए speed से ज़्यादा सही type checking महत्वपूर्ण है

  • Astral टीम का धन्यवाद। हम Pydantic का बहुत इस्तेमाल करते हैं, इसलिए यह सुनकर उत्साह है कि Ty के official release में first-class support आने वाला है
    अभी हम Pyright और Mypy दोनों चलाते हैं, और दोनों अलग-अलग तरह की errors पकड़ते हैं, इसलिए थोड़ा दोहराव-सा लगता है
    इस तालिका के अनुसार Pyright एक superset बताया गया है, लेकिन मेरा वास्तविक अनुभव अलग रहा
    यह 2 साल पुराना विश्लेषण है, इसलिए अब स्थिति अलग हो सकती है। जानना चाहूँगा कि क्या किसी ने बड़े codebase में सिर्फ़ Pyright पर एकीकरण किया है

    • मैं भी mypy का शुरुआती उपयोगकर्ता रहा हूँ, इसलिए जब Pyright VS Code में जोड़ा गया तो मैंने दोनों की तुलना की थी
      कई बार mypy ज़्यादा flexible और accurate inference करता था, जबकि Pyright में false positives इतने थे कि मैंने उसे बंद भी कर दिया था
      आजकल Pyright काफ़ी बेहतर हो गया होगा, लेकिन BasedPyright तो उल्टा गैर-उत्पादक लगा
      community में mypy को कमतर दिखाकर Pyright की बहुत तारीफ़ करने का माहौल है, लेकिन मेरा अनुभव उससे थोड़ा अलग है
    • फिर से कहूँगा, spec compliance tests वास्तविक user experience को नहीं दर्शाते
      वे मुख्यतः annotations की semantics पर केंद्रित होते हैं, इसलिए type checker चुनने का आधार बनाने के लिए उपयुक्त नहीं हैं
      (मैंने भी Python Typing Council में यह spec और tests बनाए हैं)

  • शीर्षक “Ty beta release announcement” होना ज़्यादा उचित लगता
    मुझे Pyrefly , Pyright से ज़्यादा पसंद था, लेकिन हाल के एक bug की वजह से पुराने version पर pin करना पड़ा, जो असुविधाजनक था
    मैंने Ty install करने की कोशिश की तो Cursor version compatibility error आ गया

    • अगर कोई अतिरिक्त error message हो तो कृपया issue दर्ज करें। मैं कई हफ़्तों से Cursor में Ty extension ठीक से इस्तेमाल कर रहा हूँ, इसलिए इसे reproduce करना मुश्किल है
    • (मैं Pyrefly maintainer हूँ) उस crash को भी Pyrefly repository में issue के रूप में दर्ज कर दें तो अच्छा होगा

  • अब भी समझ नहीं आता कि एक ही language के लिए इतने सारे type checkers क्यों मौजूद हैं
    क्या library बनाने वालों को हर checker के लिए test करना चाहिए? क्या developers को सिर्फ़ वही libraries इस्तेमाल करनी चाहिए जो किसी खास checker को support करती हों?

    • Python एक duck typing + optional type annotations वाली language है, इसलिए अलग-अलग implementations आना लगभग तय है
    • कुछ अंतर caller inference की सीमा या explicit type requirement policies की वजह से भी हैं
      package boundaries पर explicit types चाहिए होते हैं, लेकिन internal code में अस्पष्टता काफ़ी होती है
      Astral खास तौर पर incremental processing performance को एक प्रमुख design goal मान रहा है
    • व्यवहार में ज़्यादातर लोग mypy को आधार बनाकर test करते हैं। Pyright, VS Code के default extension की वजह से धीरे-धीरे अपना प्रभाव बढ़ा रहा है
      ज़रूरत पड़े तो compatibility सुनिश्चित करने के लिए सीधे type stubs भी दिए जा सकते हैं

  • यह बात पसंद आई कि Ty का रुख “type checker को खुश करने के लिए annotations जोड़ने की ज़रूरत नहीं” वाला है
    पुराने checkers मामूली warnings से परेशान करते थे, लेकिन Ty असली logical errors अच्छी तरह पकड़ता है

  • आज पहली बार पता चला कि Ty language server (LSP) की भूमिका भी निभाता है
    यानी Neovim या VSCode में यह mypy और Pyright दोनों की जगह ले सकता है

  • जानना चाहूँगा कि Django support कैसा है। Django में magic code बहुत होता है, इसलिए type checkers के लिए उसे संभालना कठिन होता है

    • Ty अभी Django को support नहीं करता और इसमें plugin system भी नहीं है
      अगर आप Django इस्तेमाल करते हैं, तो फिलहाल mypy या Pyright बनाए रखना बेहतर होगा

  • अगर Ty तेज़ न भी हो, तो सिर्फ़ intersection types (A & B) support की वजह से भी यह इस्तेमाल करने लायक लगता है
    standard Python type system में यह feature नहीं है, इसलिए इसे देखकर अच्छा लगा

  • सोच रहा हूँ कि क्या Ruby में भी uv जैसा कुछ है। Python या TypeScript में मैं uv या bun इस्तेमाल करता हूँ, लेकिन Ruby कुछ पीछे छूटा हुआ लगता है

    • Rv नाम का एक नया Ruby management tool है। शायद वही उसका विकल्प बन सके