Python के प्रयोगात्मक JIT को हटाया जाएगा
Python के core developers ने CPython से प्रयोगात्मक just-in-time (JIT) compiler हटाने का निर्णय लिया है, क्योंकि दीर्घकालिक रखरखाव अनिश्चित है, वास्तविक दुनिया में speedups सीमित हैं, और यह एक व्यापक रूप से उपयोग होने वाले, security-sensitive runtime में जटिलता जोड़ता है। टिप्पणीकार इस बात पर बँटे हुए हैं कि क्या यह स्थिरता और tooling compatibility की रक्षा करने वाला स्वस्थ governance है, या ऐसी bureaucracy है जो मुख्य implementation में महत्वाकांक्षी performance work को लगभग असंभव बना देती है। कई लोग PyPy, GraalPy, Cython, Numba, या तेज़ भाषाओं में पूर्ण पुनर्लेखन जैसे विकल्पों की ओर इशारा करते हैं, जबकि यह भी अफसोस जताते हैं कि Python का ecosystem और C-API की विचित्रताएँ भाषा की लोकप्रियता को state-of-the-art performance के साथ जोड़ना असाधारण रूप से कठिन बना देती हैं.
JIT हटाने पर कुल प्रतिक्रिया
- कई लोगों ने निराशा जताई; उन्हें उम्मीद थी कि JIT “pure Python” को सार्थक रूप से तेज़ करेगा और Cython/Rust में पुनर्लेखन की ज़रूरत कम करेगा।
- दूसरों के लिए यह फैसला उचित लगता है, क्योंकि गति में बढ़ोतरी अक्सर केवल ~10% के आसपास बताई गई, जबकि जटिलता और रखरखाव का बोझ बहुत बड़ा था।
- कुछ लोग इसे Python के एक और असफल JIT प्रयास के रूप में देखते हैं (Psyco, Unladen Swallow, आदि के बाद), और इससे उनका यह निराशावाद और मजबूत होता है कि CPython कभी एक मज़बूत in-tree JIT पाएगा भी या नहीं।
प्रक्रिया, शासन, और “ब्यूरोक्रेसी”
- एक पक्ष का तर्क है कि समिति-आधारित प्रक्रिया और सख्त PEP आवश्यकताओं ने एक आशाजनक प्रयोग को मार दिया, और वे “poison‑pill” जैसी शर्तों का हवाला देते हैं, जैसे व्यापक tooling support और सफलता के मापदंड।
- दूसरा पक्ष कहता है कि प्रक्रिया ने ठीक वैसा ही काम किया जैसा करना चाहिए था: एक बार कुछ
mainपर आ जाए, तो उसका दायरा, रखरखाव योजना, और compatibility story स्पष्ट होनी चाहिए; खुले-ended प्रयोग किसी वैश्विक infrastructure भाषा के core में नहीं होने चाहिए। - इस बात पर असहमति है कि यह “ब्यूरोक्रेसी” है या एक परिपक्व ecosystem के लिए आवश्यक शासन।
Python के लिए JIT की तकनीकी चुनौतियाँ
- Python की अत्यधिक गतिशीलता को एक मूल समस्या बताया गया है:
__dict__,__class__का reassignment, monkey‑patching, metaprogramming, pytest bytecode rewriting, C extensions, और introspection APIs optimization को जटिल बनाते हैं। - कुछ लोगों का कहना है कि ये समस्याएँ JavaScript या Ruby की semantics से मूलतः कठिन नहीं हैं, और सफल JITs (V8, LuaJIT, PyPy, GraalPy) दिखाते हैं कि पर्याप्त निवेश से यह संभव है।
- अन्य लोग नोट करते हैं कि CPython का C API implementation details लीक करता है, जिससे JIT और GIL removal जैसे गहरे बदलाव विशेष रूप से जोखिमपूर्ण हो जाते हैं।
आज का प्रदर्शन और मौजूदा विकल्प
- आम तौर पर जिन विकल्पों का उल्लेख किया गया: C extensions, Cython, Numba, mypyc, PyPy, GraalPy, Rust (PyO3 के माध्यम से), और Go rewrites।
- आलोचना: ये विकल्प बिखरे हुए हैं, और हर एक की अपनी सीमाएँ हैं (version lag, C-API issues, सीमित subsets, deployment complexity)। बहुत से लोग फिर भी “बस तेज़ CPython” चाहते हैं।
- कुछ लोगों का तर्क है कि Python व्यावहारिक सीमाओं तक पहुँच चुका है: यदि performance एक मूल आवश्यकता है, तो समाधान hot paths या पूरे systems को तेज़ भाषाओं में rewrite करना है, संभवतः AI सहायता के साथ।
सुरक्षा और विश्वसनीयता संबंधी चिंताएँ
- कुछ लोग JS engines और PHP के सुरक्षा इतिहास को देखते हुए JIT से बचने के निर्णय का समर्थन करते हैं; वे CPython की सरल bytecode VM और अपेक्षाकृत कम CVE संख्या को महत्व देते हैं।
- अन्य लोग जवाब देते हैं कि Python बहुत कम ही untrusted code चलाता है, इसलिए JIT-विशिष्ट exploit जोखिम उतने प्रभावशाली नहीं हैं जितनी सुरक्षा समस्याएँ पहले से ही C extensions के कारण मौजूद हैं।
वैकल्पिक दिशाएँ और उपसमुच्चय
- कई लोग सुझाव देते हैं कि Python का एक अधिक सख्त, typed subset, जिसमें AOT/JIT हो (जैसे “Static Python”, Mojo-जैसा, CinderX style), बड़े speedups के लिए शायद एकमात्र टिकाऊ रास्ता है।
- यह लेकर संदेह भी है कि Python की संस्कृति और मौजूदा dynamic features को देखते हुए, ऐसे subset को standardize करना भारी bikeshedding के बिना संभव होगा भी या नहीं।