Python के दो नए Rust-आधारित type checker, Pyrefly और Ty की तुलना

• हाल ही में Meta के Pyrefly और Astral के Ty नाम के दो Rust-आधारित Python type checker सामने आए हैं, जो मौजूदा mypy और pyright की तुलना में बेहद बेहतर प्रदर्शन और एक नया typing paradigm दिखाते हैं
• Pyrefly आक्रामक type inference और open source को लक्ष्य बनाता है, जबकि Ty “gradual guarantee” सिद्धांत अपनाकर type error की संभावना को न्यूनतम रखने पर ज़ोर देता है
• दोनों टूल अभी शुरुआती alpha version में हैं, लेकिन अलग-अलग प्रोजेक्ट्स पर किए गए benchmark में Ty ने औसतन अधिक तेज़ execution speed दर्ज की
• Incremental analysis में Pyrefly module स्तर पर काम करता है, जबकि Ty function target स्तर तक अधिक सूक्ष्म incrementality देता है, इसलिए दोनों की उपयोगिता और संरचना अलग है
• Ty intersection types और negation types जैसे अभिनव type system फीचर पेश करता है, और ज़्यादा सहज व स्पष्ट error messages देता है

---

Pyrefly और Ty का परिचय

• Pyrefly और Ty Rust में बनाए गए Python type checker हैं
• Pyrefly को Meta (पूर्व Facebook) ने विकसित किया है, और यह मौजूदा OCaml-आधारित Pyre की जगह लेता है
• Ty को Astral ने विकसित किया है, और Astral uv, ruff जैसे Python tools के लिए जाना जाता है
• दोनों प्रोजेक्ट open source के रूप में उपलब्ध हैं, लेकिन अभी औपचारिक release से पहले alpha stage में हैं
• दोनों टीमों ने PyCon 2025 Typing Summit में अपनी vision, goals और approach पेश की

समानताएँ

• दोनों Rust में विकसित किए गए हैं और incremental checking को support करते हैं
• Python code की AST parsing के लिए ruff का उपयोग करते हैं
• command-line type checking, LSP/IDE integration support जैसी development environment connectivity भी मजबूत है

अंतर 1: गति

PyTorch benchmark

• Ty, Pyrefly से लगभग 2~3 गुना तेज़ है, और दोनों ही मौजूदा mypy, pyright से 10~20 गुना तेज़ हैं
• Pyrefly का लक्ष्य Pyre की तुलना में 35 गुना और mypy/pyright की तुलना में 14 गुना performance improvement हासिल करना है
• Ty को मौजूदा पीढ़ी के type checker की तुलना में एक या दो orders of magnitude तेज़ बनाने के लक्ष्य से डिज़ाइन किया गया है

Django benchmark

• Ty सबसे तेज़ रहा, और उसके बाद Pyrefly आया
• Pyright ने स्पष्ट रूप से धीमा परिणाम दिखाया

mypy repository benchmark

• इसी तरह के परिणाम में Ty सबसे तेज़ रहा, और Pyrefly मामूली अंतर से उसके पीछे रहा
• mypy और pyright ने काफ़ी धीमा execution time दर्ज किया

अंतर 2: typing goals

Pyrefly

• कोड में अलग से explicit type न होने पर भी जहाँ तक संभव हो type infer करके error पकड़ने की रणनीति अपनाता है
• ज़्यादा आक्रामक type inference के ज़रिए code stability को अधिकतम करने का लक्ष्य रखता है

Ty

• Gradual guarantee (क्रमिक आश्वासन) सिद्धांत लागू करता है
• इसे इस तरह डिज़ाइन किया गया है कि काम कर रहे code से explicit type हटाने पर type error उत्पन्न न हो
• type annotation न होने पर भी error नहीं देता, और केवल ज़रूरत पड़ने पर अतिरिक्त annotation मांगता है
• उदाहरण: explicit type के बिना किसी field में value assign करने पर भी type error नहीं होता, बल्कि उसे Unknown | None आदि के रूप में संभाला जाता है

अंतर 3: incremental analysis की पद्धति

• Pyrefly: बदली हुई files (modules) और उन पर निर्भर modules का ही दोबारा analysis करता है (module-level incrementality)
• Ty: Rust के Salsa framework का उपयोग करके function-level तक सूक्ष्म incrementality देता है
• module-level approach को पर्याप्त तेज़ माना जाता है, जबकि function-level approach codebase को जटिल बना सकती है (यही दोनों टूल की रणनीतिक भिन्नता है)

अंतर 4: फीचर (type system और support)

Pyrefly की खूबियाँ

• Implicit type inference बहुत शक्तिशाली है
• explicit type के बिना भी function return value, dictionary, list जैसी जटिल types का analysis करके error पकड़ लेता है
• generic, overload, wildcard import जैसी जटिल typing समस्याओं पर विशेष ध्यान देकर डिज़ाइन किया गया है
• generic type inference की accuracy, Ty से बेहतर है

Ty की विशेषताएँ

• “gradual guarantee” के कारण explicit type न होने पर भी type को स्वतंत्र रूप से बदलने की अनुमति देता है
• intersection types और negation types जैसे अभिनव type system फीचर्स को support करता है
• error messages बहुत स्पष्ट और सहज ढंग से डिज़ाइन किए गए हैं
• list आदि में अलग-अलग types assign करने की स्वतंत्रता देता है, और type के Unknown मान को system स्तर पर शामिल करता है

सीमाएँ / alpha status

• दोनों प्रोडक्ट अभी alpha stage में हैं, इसलिए type inference या कुछ फीचर अभी अधूरे हैं
• उदाहरण के लिए, Ty की list type inference जैसी कुछ चीज़ों में अभी परिपक्वता की कमी है

विस्तृत फीचर तुलना

Implicit type inference

• Pyrefly return type और collection object type को सक्रिय रूप से infer करके revealed type और errors को स्पष्ट रूप से दिखाता है
• Ty में inference कम पड़ने पर Unknown या @Todo लौटाया जाता है

Generics

• Pyrefly और Ty दोनों सामान्य generic type समस्याओं को अच्छी तरह संभालते हैं
• Pyrefly, type parameter के बिना बनाए गए instance के type interpretation में बढ़त रखता है
• दोनों checker covariance/contravariance समस्याओं में mypy और pyright की तुलना में कुछ कमज़ोर दिखते हैं

Error messages

• Ty concise और आसानी से पढ़े जा सकने वाले error messages पर ज़ोर देता है
• Pyrefly, mypy और pyright की तुलना में ऐसे messages देता है जिन्हें एक नज़र में समझना आसान है

Intersection / negation types

• केवल Ty ही intersection types (&) और negation types (~) को support करता है, जिससे नीचे जैसी जटिल type operations संभाली जा सकती हैं

  • उदाहरण: WithX | Other type में अगर x attribute मौजूद हो, तो Ty अपने-आप WithX में branch कर देता है
  • उदाहरण: अगर कोई विशेष subclass न हो, तो type को MyClass & ~MySubclass के रूप में interpret किया जाता है

• इस तरह के intersection और negation types, type theory में काफ़ी उन्नत फीचर माने जाते हैं

अन्य उन्नत उदाहरण

• Ty का type system Diophantine equations जैसी जटिल operations में भी इस्तेमाल किया जा सकता है
• इसके tests Markdown documents में लिखे जाते हैं (संदर्भ: Astral ruff का mdtest resource)

निष्कर्ष और आगे की दिशा

• Python ecosystem में बेहद तेज़ और नए तरह के type checker आ चुके हैं
• Ty का मुख्य फ़ोकस क्रमिक type safety पर है, जबकि Pyrefly का मुख्य फ़ोकस सक्रिय type inference पर है
• दोनों टूल अभी शुरुआती अवस्था में हैं, इसलिए भविष्य में इनके फीचर्स के एक-दूसरे के करीब आने या आगे विकसित होने की पर्याप्त संभावना है
• इन्हें आधिकारिक sites पर आज़माया जा सकता है, और VSCode, Cursor जैसे प्रमुख editors के plugins भी उपलब्ध हैं
• यह भी चर्चा है कि भविष्य में Google भी Go-आधारित type checker को open source कर सकता है, जिससे Python type analysis का क्षेत्र और समृद्ध हो सकता है

उपयोग / संदर्भ

• Pyrefly: pyrefly.org/sandbox
• Ty: play.ty.dev
• Astral का Ty Markdown-आधारित tests का उपयोग करता है (विस्तृत path के लिए ruff repo का mdtest देखें)
• आधिकारिक documentation, editor plugins और package installation commands भी उपलब्ध हैं

[q8840]

लगता है ty में अगर इस्तेमाल किए गए function पर return type नहीं लिखा हो तो वह उसे हमेशा unknown मानता है; और जांच तभी करता है जब आप सेव करते हैं
pyrefly में बिना लिखे भी inference हो जाता है, और typing के दौरान भी जांच करता है

[GN⁺]

Hacker News की राय

• ty के डेवलपर के रूप में इस बात पर खुशी जताई गई कि ty और pyrefly पर धीरे-धीरे अधिक ध्यान जा रहा है, लेकिन साथ ही यह फिर से ज़ोर देकर कहा गया कि दोनों प्रोजेक्ट अभी पूर्ण नहीं हैं; फीचर अभी लागू न होने के कारण ऐसे उदाहरण भी मिलेंगे जहाँ कुछ “अजीब” लगे, और ऐसे में यह समझना चाहिए कि हो सकता है वह हिस्सा अभी बना ही न हो; यह भी ध्यान रखना ज़रूरी है कि Python बहुत बड़ा और विविध भाषा-परिसर है

  • ty की markdown-स्टाइल टेस्टिंग पद्धति बहुत पसंद आई; यह कि टेस्ट दस्तावेज़ीकरण का काम भी करते हैं, एक शानदार विचार लगा; यह जानने की जिज्ञासा जताई गई कि क्या यह तरीका Rust के documented code examples से प्रेरित है

  • टाइप को उजागर करने वाले हिस्से को @TODO से चिह्नित करने पर हँसी आई, लेकिन फिर लगा कि यह काफ़ी चतुर और उपयोगी युक्ति है

  • TypeScript का अनुभव रखने वाले एक पाठक ने कहा कि type inference, type narrowing, और अलग-अलग Python type checker के भिन्न व्यवहार जैसे प्रयोग उन्हें रोचक लगते हैं; फिर भी उनका मानना है कि एक तेज़ और भरोसेमंद type checker की सख्त ज़रूरत है, और Python इस मामले में काफ़ी पीछे लगता है; type checker को code productivity और reliability बढ़ानी चाहिए, इसलिए वे ऐसे प्रोजेक्ट्स का समर्थन करते हैं

  • Rust डेवलपर के नज़रिये से “Rust के लिए scripting language” पर सवाल उठाया गया: क्या ऐसा कोई नेटवर्क या शोध-समुदाय है जो ऐसी भाषा पर काम कर रहा हो जिसकी syntax Rust से अच्छी तरह मेल खाए, जो Rust types को native रूप से import कर सके, और तेज़ compile/hot reload दे सके; साथ ही यह भी पूछा गया कि भले syntax अलग हो, क्या Python यह भूमिका निभा सकता है; संबंधित लिंक दिया गया https://news.ycombinator.com/item?id=44050222

• Python का बहुत अनुभव न रखने वाले एक बाहरी दृष्टिकोण से कहा गया कि यदि type hints के उपयोग में रुचि हो तो Reddit पोस्ट https://www.reddit.com/r/Python/comments/10zdidm/why_type_hinting_sucks/ देखना उपयोगी हो सकता है; हालाँकि उस पोस्ट को बहुत गंभीरता से नहीं लेना चाहिए, लेकिन बात यह है कि चाहे type tools कितने भी अच्छे हों, “good practices” पहले आती हैं; उदाहरण के लिए Django या Meta जैसी बड़ी codebase में consistent usage और strict type checking तभी संभव है जब डेवलपर्स को सुझाए गए conventions मानने पर मजबूर किया जाए; Python में C++ की तरह बहुत ज़्यादा फीचर और उदार runtime है, इसलिए व्यवहार में उसका केवल एक सीमित subset ही manage करना आसान होता है; लेकिन वह subset व्यक्ति और उद्देश्य के हिसाब से बदल सकता है; इसकी तुलना Rust डेवलपर्स और Linux kernel डेवलपर्स के बीच अधिक सख्त type system को लेकर होने वाले टकराव से भी की गई

  • उस Reddit पोस्ट की एक शीर्ष टिप्पणी को उद्धृत करते हुए कहा गया कि “‘Any’ तो इस्तेमाल कर ही सकते हैं” कहकर चर्चा को ख़ारिज कर देना उचित नहीं; वास्तविक मामलों में अधिक स्पष्ट type declarations लाइब्रेरी functions के भविष्य के बदलाव या अप्रत्याशित input values के कारण होने वाली त्रुटियों को पहले से रोक सकते हैं; इसलिए Python code की maintainability और reliability के लिए type checking अनिवार्य बताई गई

  • यह निष्कर्ष भी सामने आया कि Python type checking पर बहुत समय और मेहनत लगाने के बजाय किसी अधिक उपयुक्त statically typed भाषा पर जाना और केवल interop layer के रूप में Python का उपयोग करना बेहतर हो सकता है; यह हमेशा संभव नहीं होता, लेकिन Python को ज़बरदस्ती ढालने में समय बहुत नष्ट होता है

  • Python की शक्तिशाली लेकिन जटिल सुविधाओं—जैसे meta class, descriptor, __call__, object.__new__, name mangling, self.__dict__—की आलोचना की गई कि इनमें बहुत अधिक magic है और ये code readability को काफ़ी घटाते हैं; व्यक्तिगत रूप से ऐसे फीचर्स का उपयोग न करने की बात कही गई

  • यह भी पूछा गया कि किसी भाषा का वास्तविक उपयोग किए बिना उसके बारे में राय देने की प्रवृत्ति कहाँ से आती है; Python डेवलपर्स तो इसे इस्तेमाल करते हुए गहराई से समझते हैं, लेकिन non-users बाहरी आधारों पर भाषा की आलोचना करते हैं, यह अजीब लगा; साथ ही contrived example के आधार पर बहस करने की प्रवृत्ति की ओर इशारा किया गया

  • कई वर्षों से Python इस्तेमाल करने वाले एक व्यक्ति ने साफ़ कहा कि सबसे बड़ी गलती type hints और type checker का बिल्कुल उपयोग न करना है

• ty की “gradual guarantee” अवधारणा को रोचक बताया गया—यानी यदि एक type annotation हटा दी जाए तो type error नहीं आना चाहिए; इसे dynamic code वाले Python के लिए सबसे उपयुक्त तरीका माना गया

  • इसके जवाब में कहा गया कि gradual typing की संरचना ऐसी होती है कि code में कहीं भी “any” (अनिर्धारित type) मौजूद हो सकता है और तब भी कोई warning नहीं मिलती; परिणामस्वरूप महत्वपूर्ण code भी पूर्ण type safety से वंचित रह सकता है; mypy के उपयोग के अनुभव में यह बड़ी समस्या रही, और “इस file को पूरी तरह statically type-check करो” जैसी घोषणा की सुविधा आवश्यक बताई गई; व्यक्तिगत राय में “gradual” typing लगभग anti-pattern जैसी है, और शायद “soft typing” शब्द अधिक उपयुक्त हो सकता है

  • दूसरी ओर यह तर्क दिया गया कि मौजूदा codebase में gradual typing के अलावा व्यवहारिक विकल्प नहीं है; legacy Python codebase में mypy के साथ type hints जोड़ने के अनुभव से “module-level opt-in” सबसे उचित लगा; यदि pyrefly इसे support नहीं करता तो उसकी practical utility सीमित रह सकती है; हालाँकि LLM code generation के संदर्भ में बहुत तेज़ और strict type checker उपयोगी हो सकता है

  • इसे TypeScript के शुरुआती adoption जैसा बताया गया, जहाँ बड़े मौजूदा projects के लिए सहज onboarding महत्वपूर्ण था; धीरे-धीरे noImplicitAny या strict विकल्प module दर module चालू करके अंततः मज़बूत type validation वातावरण तक पहुँचा जा सकता है

  • एक Rust programmer ने भी कहा कि “gradual guarantee” उन्हें सबसे तर्कसंगत लगती है

  • वहीं एक अन्य राय में कहा गया कि gradual typing support व्यक्तिगत रूप से बहुत आकर्षक नहीं लगता; Python की dynamic type system पहले से ही अस्थिर है, इसलिए type annotations जोड़ने का आधा उद्देश्य उसी अनिश्चितता को नियंत्रित करना है; इस कारण no-implicit-any या strict mode जैसे विकल्प अनिवार्य होने चाहिए

• Astral के tooling को Python ecosystem के लिए ताज़ी ऊर्जा माना गया, लेकिन उसके “long-term outlook” पर प्रश्न उठाया गया: क्या यह आगे चलकर सीधे Python में एकीकृत होगा? क्या 5 साल में गायब हो जाएगा? क्या subscription-आधारित rug pull बन जाएगा?

  • यह आशंका जताई गई कि business source license जैसे मॉडल के तहत Astral tools का production deployment करने वाली कंपनियों को enterprise subscription लेने की दिशा में धकेला जा सकता है; मौजूदा उत्पाद शायद अभी सीधे उसी उद्देश्य के लिए न हों, लेकिन venture capital के दृष्टिकोण से ऐसा मॉडल संभव लगता है

  • आधिकारिक घोषणा का हवाला देते हुए कहा गया कि Astral ने साफ़ लिखा है कि वह tools के ऊपर विविध services बेचेगा; संदर्भ लिंक: https://astral.sh/blog/announcing-astral-the-company-behind-ruff

  • यह भी कहा गया कि ऐसी चिंता केवल Astral तक सीमित नहीं है, बल्कि सभी projects पर लागू होती है; विशेषकर Facebook के tooling के बारे में चेतावनी दी गई कि समय के साथ उनके unmaintained होकर “छूट जाने” का जोखिम अधिक रहता है; अंततः उपयोगकर्ताओं को स्वयं जोखिम उठाना ही पड़ता है

  • Reddit के एक उपयोगकर्ता की राय उद्धृत करते हुए कहा गया कि VC का मूल मॉडल अक्सर यही होता है कि या तो किसी FAANG/बिग टेक द्वारा acquisition हो, या कंपनी इतनी बड़ी हो जाए कि “acqui-hire” जैसे परिणाम निकलें; Astral के लिए भी acquisition और talent absorption जैसा परिदृश्य संभव है

  • हाल की अफ़वाहों का ज़िक्र हुआ कि Astral बड़े enterprises के लिए dedicated tools, जैसे hosted private package registry, भी तैयार कर रहा है

• “my_list = [1, 2, 3]” उदाहरण में mypy, pyrefly, और pyright my_list.append("foo") को type error मानते हैं, लेकिन ty बिना किसी अतिरिक्त घोषणा के इसे स्वीकार कर लेता है; इस पर कहा गया कि व्यावहारिक विकास में single-type list का उपयोग सामान्य है, इसलिए type checker को इसे आधार मानना चाहिए; Python अनुमति देता है, इसका मतलब यह नहीं कि type validation ढीली हो; इस नीति की तीखी आलोचना की गई और पूछा गया कि क्या यह शुरुआती उपयोगकर्ताओं के code के लिए optimised रुख है

  • इस पर ty डेवलपर ने स्पष्ट किया कि “list literal type inference अभी पूरा नहीं हुआ है”; अभी केवल list[Unknown] प्रयोग हो रहा है और Unknown एक Any-जैसा gradual type है, इसलिए append में सब कुछ स्वीकार हो जाता है; आगे अधिक सटीक inference की योजना है, और संबंधित चर्चा के लिए issue लिंक दिया गया: https://github.com/astral-sh/ty/issues/168

  • एक और राय यह थी कि यह शुरुआती उपयोगकर्ताओं के लिए optimisation नहीं, बल्कि legacy code compatibility के कारण एक व्यावहारिक मजबूरी है; बड़े untyped codebase में type checker लाने के लिए यह ज़रूरी है कि पुराना code अधिकतर वैसा ही चलता रहे, तभी adoption का बोझ कम होता है

  • इसके विपरीत यह प्रतिवाद भी आया कि “Python जो अनुमति देता है उसे नज़रअंदाज़ करके केवल निजी राय के आधार पर tooling बनाना” प्रभावी तर्क नहीं है

  • pyrefly पद्धति की समस्या के रूप में कहा गया कि बड़े untyped codebase में इसका पूर्ण adoption कठिन है, क्योंकि बहुत सारा code हाथ से बदलना पड़ता है; यदि संगठन में इसके लिए सहमति न हो तो यह आसान नहीं; Meta जैसे आंतरिक रूप से enforce कर सकने वाले वातावरण में तो यह ठीक है, लेकिन gradual adoption के लिए ty जैसी अधिक उदार पद्धति व्यवहारिक लगती है; फिर भी व्यक्तिगत रूप से mixed types पर warning देने वाले tools को अधिक पसंद किया गया

  • एक राय यह भी थी कि “यदि code वैध Python के रूप में चल सकता है, तो जब तक type को स्पष्ट रूप से सीमित न किया गया हो, type error नहीं आना चाहिए”; और यदि अधिक सख्त static subset चाहिए, तो type annotations सीधे जोड़ देनी चाहिए

• अनुभवी उपयोगकर्ता की राय में Pyrefly की पद्धति अधिक मज़बूत type inference पर आधारित है, इसलिए वास्तव में बड़े type-safe code में आवश्यक annotations बहुत कम हो जाती हैं; शुरुआती adoption कठिन हो सकता है, लेकिन लंबी अवधि में यह अधिक कुशल साबित होती है; ty को लगभग ऐसा बताया गया जैसे उसमें noImplicitAny विकल्प बंद हो

• ऐसे type checker की उम्मीद जताई गई जो notebook (live coding) integration को गंभीरता से support करे; लंबे cell चलाने से पहले static checks के जरिए त्रुटियाँ पकड़ लेना बहुत उपयोगी होगा

  • VSCode में Jupyter notebook उपयोग के अनुभव के बारे में पूछा गया; यह भी कहा गया कि pylance जैसे type checker कभी-कभी experimental code में मदद के बजाय बाधा बन जाते हैं

  • जवाब में VSCode Language Server अनुभव की सिफारिश की गई, जहाँ notebook integration और live feedback दोनों मिलते हैं; कहा गया कि यह notebook integration और interactive type checking की ज़रूरत को काफ़ी हद तक पूरा करता है

• Pyrefly के design को TypeScript के type inference approach के अधिक निकट और इसलिए व्यक्तिगत रूप से अधिक तर्कसंगत बताया गया; module-level gradual/incremental adoption को आदर्श माना गया, जबकि function-level तक जाना अत्यधिक सूक्ष्मता लगती है; performance की दृष्टि से भी module-level पर्याप्त माना गया

• यह भी कहा गया कि project में dynamic behavior अधिक हो तब भी व्यक्तिगत रूप से Pyrefly जैसी अधिक मजबूत type inference को प्राथमिकता देंगे, चाहे उससे कुछ असुविधा ही क्यों न हो

• वर्तमान में basedpyright को IDE और CI environment में उपयोग करने की बात कही गई, और इसकी stability से संतोष व्यक्त किया गया; वहीं mypy के बारे में कहा गया कि वह साधारण type tasks में भी अक्सर विफल हो जाता है, इसलिए पसंद नहीं है