Python 3.15

मूल लेख ↗ Hacker News चर्चा ↗

Python 3.15 में प्रदर्शन सुधार और कई उल्लेखनीय नई सुविधाएँ शामिल हैं, जिनमें उन्नत experimental JIT, तेज़ startup के लिए explicit lazy imports, नया sampling profiler (“tachyon”), comprehensions में unpacking, और built‑in `frozendict` type शामिल हैं। योगदानकर्ता free-threaded build के लिए नए abi3t stable ABI को interpreter variants के बीच binary compatibility आसान करने, packaging और CI जटिलता घटाने की दिशा में एक बड़ा कदम मानते हैं। चर्चा का बड़ा हिस्सा version support नीतियों पर केंद्रित है: maintainers EOL interpreters को हटाने के अवसर का स्वागत करते हैं, जबकि पुराने systems पर उपयोगकर्ता breakage और OS-bundled runtimes के बाहर अलग Python environments प्रबंधित करने की बढ़ती आवश्यकता को लेकर चिंतित हैं.

रिलीज़ पेज और वितरण की विचित्रताएँ

  • कुछ उपयोगकर्ता 3.15 रिलीज़ पेज पर टूटे हुए या गलत-एंकर वाले लिंक की रिपोर्ट करते हैं (जैसे Sentinel, lazy imports का पेज के नीचे लिंक होना)।
  • xz सोर्स टारबॉल 3.14 की तुलना में काफ़ी बड़ा है; जाँच से पता चलता है कि दस्तावेज़ों में लगभग 10MB के animated GIFs हैं (Tachyon profiler के लिए)।
    • कुछ लोग इसे अनावश्यक bloa‎t मानते हैं और हल्के SVG-आधारित docs को प्राथमिकता देंगे।
    • अन्य कहते हैं कि आलोचकों को बेहतर assets में योगदान देना चाहिए।

प्रदर्शन, JIT, और profiling

  • experimental JIT के reported 7–12% speedups (platform के अनुसार) को solid incremental gains के रूप में सराहा गया है।
  • नया Tachyon sampling profiler खास तौर पर production में running processes के profiling के लिए उपयोगी बताया गया है।

Lazy imports और startup

  • PEP 810 के explicit lazy imports को लेकर उत्साह है, खासकर बड़ी या startup-sensitive applications के लिए।
  • कुछ लोग पूछते हैं कि इसे globally सक्षम क्यों नहीं किया गया; जवाब में ये बातें सामने आती हैं:
    • import-time side effects (जैसे registries) और nondeterministic import order।
    • PEP 810 इन tradeoffs को स्पष्ट रूप से दस्तावेज़ करता है।
  • एक static analyzer (“lifeguard”) का उल्लेख है जो code को स्कैन करके पहचानता है कि कहाँ lazy imports सुरक्षित रूप से सक्षम किए जा सकते हैं।

Version support, packaging, और OS Python

  • Maintainers 3.15 का स्वागत मुख्यतः इसलिए करते हैं क्योंकि 3.10 अब EOL है, जिससे वे 3.11+ features पर निर्भर हो सकते हैं।
  • बहस:
    • Maintainers का तर्क है कि पुराने versions को अनिश्चित काल तक support करना अव्यावहारिक है; उपयोगकर्ता पुराने package versions पर रह सकते हैं, और metadata यह सुनिश्चित करती है कि pip compatible release चुने।
    • कुछ उपयोगकर्ताओं को यह चलन पसंद नहीं कि पुराने Pythons को “drop” कर दिया जाता है जबकि वे अभी भी distros या vendors द्वारा ship किए जाते हैं।
  • Enterprise/Linux distros अक्सर upstream Python support से भी अधिक समय तक चलते हैं, लेकिन parallel streams में नए interpreters भी ship करते हैं।
  • macOS का pinned/bundled Python (Xcode के माध्यम से 3.9) outdated और confusing माना जाता है; consensus यह है कि system Python से बचें और managed environments (जैसे uv, virtualenvs) का उपयोग करें।

Typing, AI, और performance

  • एक टिप्पणीकार का दावा है कि LLMs बिना typed Python पर बेहतर काम करते हैं और annotations, क्योंकि अधिकांश training data untyped है, “noise” हो सकती हैं।
  • अन्य लोग जवाब देते हैं कि:
    • आज runtime performance annotations से लाभ नहीं लेती।
    • Types फिर भी मानवीय स्पष्टता, correctness, और professional-grade code के लिए अत्यंत महत्वपूर्ण हैं।

Free-threaded Python और abi3t

  • free-threaded build के लिए नया “abi3t” stable ABI ecosystem को सक्षम करने वाला बड़ा कदम बताया गया है।
    • उदाहरण: कुछ प्रमुख libraries पहले से ही एक single wheel ship करती हैं जो 3.15+ पर GIL और free-threaded दोनों builds के साथ उपयोग की जा सकती है।
  • Maintainers stable ABIs का उपयोग करके CI में बड़े reductions का उल्लेख करते हैं और भविष्य में versions के बीच support को आसान मानते हैं।
  • इस बारे में अभी भी प्रश्न हैं कि कौन-से C APIs limited/abi3(t) surface में शामिल होंगे।

Language features और PEPs

  • कई छोटे लेकिन लंबे समय से अपेक्षित features को सकारात्मक ध्यान मिलता है:
    • comprehensions में unpacking (PEP 798)।
    • built-in frozendict (PEP 814)।
    • सभी platforms पर default encoding के रूप में UTF-8 (PEP 686), खासकर Windows और गलत-configured containers के लिए लाभदायक।
  • कुछ उपयोगकर्ता आश्चर्य करते हैं कि UTF-8 पहले से सार्वभौमिक default क्यों नहीं था, जो पिछले सूक्ष्म व्यवहार (locale-dependent) को दर्शाता है।

Language ecosystem और Rust बहस

  • एक side-thread अनुमान लगाता है कि केवल TypeScript/JavaScript, Rust, और Python ही “survive” करेंगे, और Rust में बड़े पैमाने पर rewrites होंगे (कुछ वास्तविक-world examples सहित)।
  • अन्य लोग इसका विरोध करते हैं:
    • वे स्थापित ecosystems (C, C++, Java, C#, Swift, Kotlin, COBOL, embedded C) की ओर इशारा करते हैं जो शायद गायब नहीं होंगे।
    • नोट करते हैं कि CPython का core Rust में rewrite नहीं किया जा रहा; मौजूदा प्रयास केवल कुछ Rust components की अनुमति देने की दिशा में हैं।
  • कुछ का तर्क है कि कम languages होना अच्छा होगा; अन्य विविधता और innovation को जारी रखना बेहतर मानते हैं, खासकर AI tooling के साथ।