CPython में GIL को वैकल्पिक बनाने वाले PEP 703 को मंजूरी देने का संकेत

 (discuss.python.org)
1 पॉइंट द्वारा GN⁺ 2023-07-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Python Steering Council, CPython में GIL को वैकल्पिक बनाने वाले PEP 703 को स्वीकार करने की दिशा में है, और no-GIL प्रस्ताव तथा PEP 703 दोनों पर समुदाय की प्रतिक्रिया भी कुल मिलाकर सकारात्मक रही है
  • दीर्घकालिक लक्ष्य no-GIL build को एकमात्र build बनाना है, और with-GIL तथा no-GIL build के साथ extension module ecosystem का स्थायी रूप से बंट जाना टालना है
  • परिवर्तन प्रक्रिया में backward compatibility सबसे बड़ी बाधा है, और no-GIL समर्थन के लिए बदला गया third-party code, with-GIL build में भी लगातार काम करना चाहिए
  • योजना 3-चरणीय transition की है: अल्पकालिक experimental build, मध्यम अवधि का supported build, और दीर्घकालिक default build; experimental build Python 3.13 में आ सकता है, लेकिन 3.14 तक खिसकना भी समस्या नहीं माना जा रहा
  • default build में बदलाव से पहले community support, API, packaging, और distribution अनुभव की पुष्टि करनी होगी; और अगर भ्रम लाभ से ज्यादा हो तो PEP 703 को रोककर दूसरा समाधान खोजना होगा

Steering Council की PEP 703 स्वीकार करने की दिशा

  • Python Steering Council ने PEP 703 को स्वीकार करने की मंशा जताई है
  • no-GIL proposal survey में कुल मिलाकर सकारात्मक प्रतिक्रिया मिली, और Steering Council भी सामान्य विचार तथा PEP 703 दोनों के प्रति broadly positive है
  • हालांकि स्वीकार किए जाने के विवरण पर अभी काम चल रहा है, और आने वाले कुछ हफ्तों में इसे अंतिम रूप दिया जाएगा

स्थायी विभाजन के बिना आगे बढ़ने के transition सिद्धांत

  • लंबे समय में, संभवतः 5 साल या उससे अधिक की अवधि में no-GIL build ही एकमात्र build बनना चाहिए
    • with-GIL build और no-GIL build का स्थायी रूप से अलग-अलग बने रहना वांछित नहीं है
    • extension module ecosystem भी इन दो build में स्थायी रूप से विभाजित न हो, यह लक्ष्य है
  • backward compatibility को बहुत सावधानी से संभालना होगा
    • वे एक और Python 3 transition जैसी स्थिति नहीं बनाना चाहते
    • भले ही no-GIL build के समर्थन के लिए third-party code बदला जाए, वे बदलाव with-GIL build में भी काम करने चाहिए
    • पुराने Python versions के साथ backward compatibility के मुद्दे अलग से देखे जाने चाहिए
    • यह Python 4 नहीं है
  • ABI compatibility requirements, दोनों build के विवरण, और backward compatibility पर असर की अभी समीक्षा की जा रही है

default switch से पहले जांचने वाली शर्तें

  • no-GIL build को default बनाने से पहले यह सुनिश्चित करना होगा कि community support पर्याप्त है
  • सिर्फ default बदलकर समुदाय को जरूरी काम खुद ढूंढने के लिए नहीं छोड़ा जा सकता
  • core developers को नए build mode और उससे जुड़े पहलुओं का प्रत्यक्ष अनुभव होना चाहिए
    • मौजूदा code की thread safety ठीक करते समय नए C API और Python API की जरूरत पड़ सकती है
    • इस प्रक्रिया में मिली समझ Python community के साथ साझा की जानी चाहिए
    • यह भी देखना होगा कि core developers जिन बदलावों की मांग कर रहे हैं, और समुदाय से जिन बदलावों की अपेक्षा है, वे स्वीकार्य स्तर के हैं या नहीं
  • no-GIL को default बनाने से पहले, अगर लगे कि बदलाव बहुत ज्यादा भ्रम पैदा कर रहे हैं और लाभ कम है, तो दिशा बदलने की गुंजाइश होनी चाहिए
    • ऐसी स्थिति में पूरा काम वापस लेने का फैसला भी संभव होना चाहिए
    • इसलिए no-GIL-विशेष code किसी हद तक पहचाना जा सकने वाला होना चाहिए

3-चरणीय transition योजना

  • अल्पकाल में no-GIL build को experimental build mode के रूप में जोड़ा जाएगा
    • संभव है कि यह Python 3.13 में शामिल हो
    • Python 3.14 तक टलना भी समस्या नहीं माना जा रहा
    • experimental status का मकसद यह साफ करना है कि core developers इस build mode का समर्थन करते हैं, लेकिन यह उम्मीद नहीं की जानी चाहिए कि समुदाय तुरंत इसका समर्थन करेगा
    • API design, packaging, और distribution के स्तर पर community support संभव बनाने में समय लगेगा
    • distributions द्वारा experimental no-GIL build को default interpreter के रूप में देना अनुशंसित नहीं है
  • मध्यम अवधि में no-GIL build को supported target बनाया जाएगा, लेकिन अभी default नहीं बनाया जाएगा
    • यह भरोसा होना चाहिए कि production उपयोग के लिए community support पर्याप्त है
    • इसी चरण में no-GIL को default बनाने के लिए लक्ष्य तिथि या Python version तय किया जाएगा
    • समय-सीमा काफी हद तक API changes की backward compatibility, stable ABI handling, और समुदाय की नजर में जरूरी काम की मात्रा पर निर्भर करेगी
    • इसमें कम से कम 1~2 साल, या उससे भी अधिक समय लग सकता है
    • supported target घोषित होने पर कुछ distributors no-GIL को default के रूप में देना शुरू कर सकते हैं, लेकिन यह इस बात पर निर्भर करेगा कि उस समय तक कितने Python packages no-GIL का समर्थन करते हैं
  • दीर्घकाल में no-GIL को default बनाकर GIL के अवशेष हटाने का लक्ष्य है
    • backward compatibility को अनावश्यक रूप से नहीं तोड़ा जाएगा
    • अगर दो सामान्य build modes लंबे समय तक बनाए रखे गए, तो test resources और debugging scenarios दोगुने होने जैसे कारणों से समुदाय पर बोझ बढ़ सकता है
    • फिर भी जल्दबाजी नहीं की जा सकती, और इस चरण तक पहुंचने में अधिकतम 5 साल लग सकते हैं

लगातार पुनर्मूल्यांकन और रोकने की संभावना

  • पूरे process के दौरान Steering Council के साथ-साथ core developers को भी प्रगति और प्रस्तावित timeline का लगातार पुनर्मूल्यांकन करना होगा
  • वे नहीं चाहते कि यह काम एक और 10 साल लंबी backward compatibility लड़ाई बन जाए
  • अगर PEP 703 के समस्या बनने के संकेत दिखें, तो इसे रोककर दूसरा समाधान खोजा जा सके, यह संभव होना चाहिए
  • यह भी नियमित रूप से जांचना होगा कि जारी काम वास्तव में इतना मूल्यवान है या नहीं

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

1 टिप्पणियां

 
GN⁺ 2023-07-30
Hacker News की टिप्पणियां

  • दशकों तक बहुत सारे C library code के manuals में यह चेतावनी होती थी कि वे async, reentrant और recursive contexts में अस्थिर हैं
    फिर भी हमने उनसे निपटने के तरीके सीखे, और API instability को बहुत बढ़ाए बिना reentrant-safe versions धीरे-धीरे rollout किए गए
    जगह पर ही tokenization करने वाली string parsing, static buffers इस्तेमाल करने वाली DNS calls, Vax-विशिष्ट stack behavior पर निर्भर code जैसी चीजें थीं, और मुझे लगता है GIL एक वरदान भी था और अभिशाप भी

    • मुझे याद है कि reentrant न होने वाले functions खोजने के लिए C runtime documentation को बारीकी से खंगालना पड़ता था
      शायद उसी वजह से यह आदत बनी कि जिस API को कुछ हद तक जानते हों, उसके docs फिर भी देख लें—कहीं कोई महत्वपूर्ण detail छूट न गई हो या बदल न गई हो
      उसी दौर में cross-platform C++ करते हुए जब मैंने पहली बार Java देखा, तो उसमें concurrency, garbage collection और C++ से आसान कई features शुरुआत से मौजूद थे, और मुझे पूरा यकीन था कि यह बहुत बड़ा होगा
      बाद में mainstream developers ने Python इस्तेमाल करना शुरू किया; मेरी याद में यह मूल रूप से embeddable extension language होने के कारण simple था, इसलिए GIL भी ज्यादा समझ में आता था
    • No-GIL mode optional है, और libraries को “no-GIL compatible” के रूप में mark किया जाएगा, फिर ecosystem धीरे-धीरे ज्यादा support देने लगेगा
      ऐसा नहीं है कि कोई switch चालू करके ढेर सारे संदिग्ध C code को एक साथ तोड़ देगा
    • वह स्थिति हमेशा कायम नहीं रह सकती
      अब 128-core CPU तक आ गए हैं, और low-cost CPUs भी 6 cores के साथ आते हैं, इसलिए single-core performance से बंधे रहने की constraint समय के साथ और बड़ी होती जाएगी
    • 90s में जब मैंने C को गंभीरता से शुरू किया था, तब भी ऐसी warnings देखी थीं
      शुरुआत में लगा था कि यह समस्या कुछ हफ्तों, ज्यादा से ज्यादा कुछ महीनों में हल हो जाएगी; असल में मैं बहुत अनजान था
    • यहां बराबरी देखना मुश्किल है
      C में thread-safe न होने वाले functions के साथ interaction कहीं ज्यादा direct होता है, और C इस्तेमाल करते समय लोग आम तौर पर ज्यादा सावधान रहते हैं
      Python में global state वाले पूरे-के-पूरे C modules हैं, और ऐसे करीब 10 load करने के बाद interpreter complexity भी जोड़ दें तो जल्द ही किसी को समझ नहीं आता कि क्या हो रहा है
      अभी भी अधिकतर developers, यहां तक कि core developers भी, memory leaks check नहीं करते; tsan चलाएंगे ऐसा नहीं लगता, और चलाएंगे भी तो शायद छोटी test suite होगी जो code का सिर्फ 10% cover करती हो
      Python, खासकर AI side की software development practices को देखते हुए, मैं इस feature को लेकर बहुत निराशावादी हूं

  • दिलचस्प तो है
    Python मुख्यतः उन C shared libraries से बना है जिन्हें यह मानकर लिखा गया था कि global lock पर निर्भर रहना ठीक है
    कुछ इतनी simple हैं कि बिना lock के भी ठीक चल सकती हैं, लेकिन कुछ को अभी भी locks चाहिए होंगे और अब उन पर GIL के बिना run करने का दबाव होगा
    उनमें से कुछ अपने scope में खुद locks implement करेंगी, और शायद Python में सचमुच जिस चीज की कमी थी, वह ecosystem में जगह-जगह बिखरी हुई ad-hoc mutex calls ही थीं
    मैंने यह उम्मीद नहीं की थी कि performance के नाम पर data races और deadlocks introduce करके Python बिगड़ जाएगा
    global lock मानकर लिखी गई C library को thread-safe बनाना ऐसा काम है जिसे concurrency experts भी हतोत्साहित करेंगे, और implementation के दौरान गलती होने वाली किस्म का काम है
    मेरी hypothesis है कि Python C extensions लिखने वाले ज्यादातर लोग concurrency experts नहीं, बल्कि चुनौती से न भागने वाले अच्छे programmers हैं; इस combination में data races/hangs/segfaults लगभग अनिवार्य दिखते हैं

    • पहले चरण के तौर पर इसे explicit opt-out बनाना ठीक लगता है
      लेकिन 5 साल बाद इसे opt-in में बदलने की उम्मीद बहुत optimistic है
      हर library developer को अपनी library, यहां तक कि Python libraries भी ठीक करनी होंगी; यह कठिन काम है, और अच्छा करने पर भी कोई notice नहीं करेगा, इसलिए reward मिलना मुश्किल है
      कई libraries में multiprocessing use cases कभी थे ही नहीं, और बड़ी libraries में subtle bugs आना तय है; unreproducible complaints और developers का हार मान लेना मानो guaranteed outcome लगता है
    • Python से अक्सर call की जाने वाली ज्यादातर C libraries के दूसरे language bindings भी होते हैं, इसलिए अब तक उन्हें thread-safe होना चाहिए, ऐसा लगता है
      GIL वाला Python भी threads support करता है, इसलिए ये libraries कम से कम reentrant-safe तो होंगी
      अगर कोई library reentrant तो है लेकिन thread-safe नहीं, तो सभी calls को wrap करने वाला एक global lock जोड़ना काफी हो सकता है, और यह GIL जो करता था उससे काफी मिलता-जुलता है
      मौजूदा libraries को GIL के बिना चलाने लायक बनाना कई मामलों में अपेक्षाकृत straightforward लगता है, हालांकि parallelism की कुर्बानी देनी पड़ सकती है
      मुख्य समस्या शायद वे libraries होंगी जो C side से Python runtime में callbacks करती हैं

  • यह भले ही भोला सवाल हो, लेकिन जब asyncio और multiprocessing पैकेज मौजूद हैं, तो किसे No-GIL की जरूरत पड़ेगी, ऐसा लगता है
    Python में GIL की वजह से मुझे कभी समस्या नहीं हुई; मैंने हमेशा ThreadPool या ProcessPool चला कर, या जरूरत पड़ने पर asynchronous library इस्तेमाल कर के उसे bypass किया है
    उत्सुकता है कि क्या No-GIL के ऐसे use case हैं जिन्हें multiprocessing से हल नहीं किया जा सकता
    मुझे लगता था कि concurrency primitives के overhead के बिना single-thread execution high-performance computing के लिए सबसे अच्छा है। जैसा LMAX Disruptor ने दिखाया

    • असली मुद्दा सिर्फ performance है
      asyncio मूल रूप से single-threaded है, इसलिए single core तक सीमित है; multiprocessing multi-core है, इसलिए performance के लिए बेहतर है, लेकिन हर process अपेक्षाकृत भारी होता है और shared memory overhead भी जुड़ता है
      GIL-आधारित multithreading single-core है और सही तरीके से लिखना भी मुश्किल है
      No-GIL multithreading multi-core है, लेकिन इस्तेमाल मुश्किल है; implementation का ठीक पता नहीं, पर shared memory को multiprocessing से तेज होना चाहिए
      अगर कोई नया system design किया जा रहा हो, तो मैं इस बात से सहमत हूं कि लगभग सभी Python use cases में threads से दूर रहकर asyncio/multiprocessing इस्तेमाल करना चाहिए
      जिन Python programs को तेज multithreading चाहिए, वे अक्सर शुरुआत से ही Python में लिखे नहीं जाने चाहिए थे, लेकिन कुछ लोगों ने पहले से CPU-intensive code Python में लिख रखा है, इसलिए No-GIL व्यावहारिक है
    • ऐसे कई मामले हैं जहां No-GIL को multiprocessing से हल नहीं किया जा सकता
      मान लीजिए shared state का इस्तेमाल करके कई clients को एक साथ response देने वाला web server है; multiprocessing data भेजने-लाने के लिए pickle का उपयोग करता है, जिससे performance overhead बड़ा होता है
      उदाहरण के लिए, अगर memory में 1GB data structure रखकर parallel computation करना चाहें, तो multiprocessing से अच्छी performance के साथ यह संभालना मुश्किल है
      pickle इस्तेमाल करने पर सभी objects share नहीं किए जा सकते, और unpickleable object errors को complex data structures में debug करना बहुत कठिन होता है
      खासकर native libraries द्वारा बनाए गए objects share करना संभव नहीं हो सकता
      runtime state share करने वाली processing भी multiprocessing module से बहुत मुश्किल है, और Flask के लिए Prometheus exporter तक को सभी processes के statistics इकट्ठा करने के लिए temporary directory इस्तेमाल करने वाला अजीब hack चाहिए
    • PEP 703 में DeepMind reinforcement learning team के Manuel Kroiss बताते हैं कि GIL bottleneck के कारण उन्हें Python codebase को C++ में दोबारा लिखना पड़ता है, जिससे researchers के लिए access मुश्किल हो जाता है
      DeepMind की कई applications में वे प्रति process करीब 50–100 threads चलाना चाहते हैं, लेकिन अक्सर 10 से कम threads पर भी GIL bottleneck बन जाता है
      workaround के तौर पर subprocesses का इस्तेमाल भी करते हैं, लेकिन कई मामलों में inter-process communication overhead बहुत बढ़ जाता है, और अंततः Python codebase के बड़े हिस्से C++ में ले जाने पड़ते हैं
      web app जैसे औसत use में multiprocessing पर्याप्त हो सकता है, लेकिन Google और DeepMind जैसे large-scale AI workloads में GIL सचमुच Python के उपयोग को सीमित करता है
      Meta इस काम में 3 engineer-years लगाने को क्यों तैयार है, इसकी वजह भी यही है: https://news.ycombinator.com/item?id=36643670
    • CPU-bound समस्याओं में asyncio पूरी तरह बेकार है, क्योंकि event loop अभी भी सिर्फ single core पर चलता है
      नाम के अनुरूप, यह वाकई केवल I/O-bound समस्याओं में मदद करता है
      कई processes के बीच data sharing बहुत बड़ी पीड़ा है, और data control के साथ process orchestration करना उससे भी बड़ी पीड़ा है
      processes महंगे होते हैं, और ऊपर बताई गई data sharing की कठिनाई के कारण greenlet भी असल alternative नहीं बन पाता
    • औसत web application के लिए यह इतना क्रांतिकारी शायद नहीं होगा
      लेकिन AI और data science जैसे क्षेत्रों में, जहां Python की बड़ी भूमिका है, बहुत सारे CPU/GPU-bound threads चला पाना बड़ा फायदा है

  • कई C extensions multithreading को ध्यान में रखकर नहीं लिखे गए हैं, इसलिए समस्याएं आ सकती हैं, और सच में ऐसा होने की संभावना है
    अगर lst को किसी दूसरे thread से access किया जा सकता है, तो unsafe होने का एक छोटा उदाहरण यहां है: https://news.ycombinator.com/item?id=36649769
    अभी भी अगर C code __del__ method के जरिए Python bytecode में callback करे और वह bytecode काफी लंबा हो, शायद करीब 100 instructions जितना, तो context switch हो सकता है
    हालांकि यह बेहद दुर्लभ मामला है और बहुत-सा C extension code ऐसी स्थिति को ध्यान में रखकर नहीं लिखा गया है
    C extensions इस्तेमाल करने वाले लोग शायद इस बात पर निर्भर भी कर रहे हों कि वे atomically execute होते हैं
    उदाहरण के लिए, thread pool में numpy array डालने और निकालने का तरीका अभी तो ठीक चलता है, लेकिन GIL न हो तो टूट सकता है

    • ऐसी बहुत सारी समस्याएं सचमुच मिलेंगी, और दुर्भाग्य से वे race conditions के रूप में सामने आएंगी जिन्हें ढूंढना और debug करना मुश्किल होगा
      इसलिए proposal और काम की दिशा non-GIL mode को पूरी तरह optional रखने और default न बनाने की है
      इसे enable करके इस्तेमाल करने वाले साहसी कुछ लोगों को दशकों पुराने Python library code में सूक्ष्म race conditions खोजने और ठीक करने में भारी समय लगाने के लिए तैयार रहना होगा
      शुरुआती adopters को बहुत दर्द झेलना पड़ेगा, या ज्यादा संभावना है कि वे non-GIL को सिर्फ बहुत specialized dedicated processes तक सीमित रखेंगे जिनमें dependencies को जितना हो सके कम किया गया हो
    • मुझे यह ठीक लगता है
      यह उस स्थिति से आगे बढ़ना है जहां सिर्फ शक है कि problem होगी, उस स्थिति तक जहां पता होगा कि ठीक-ठीक problem कहां है; फिर बाकी काम उस सूची को एक-एक कर कम करना है
      code के आसपास किसी तरह का mutex जोड़ा जा सकता है, या किसी ऐसी non-native alternative implementation पर जाया जा सकता है जिसमें समस्याएं कम हों
      विरोध में दलील मुख्यतः यह लगती है कि काम बहुत है, यह नहीं कि यह असंभव है
      अगर करने वाले पर्याप्त लोग हों, तो परिणाम मिल सकता है
    • “बेहद दुर्लभ” का मतलब, उन लोगों के नजरिए से जो पेशेवर रूप से हजारों लगातार चलने वाले servers को support करने वाला parallel/asynchronous runtime संभालते हैं, असल में यह है कि चीज हमेशा टूटती है लेकिन debug करना असंभव होता है
    • मुझे लगता है CPython core developers इन समस्याओं को बहुत अच्छी तरह जानते हैं
      वरना वे लोगों को खुद No-GIL mode चुनने देने वाले चरणबद्ध approach के बजाय GIL को अचानक पूरा हटाने की योजना घोषित करते
    • मौजूदा extensions से मुकाबला कर सकने वाली concurrency-first C extensions लिखने का यह अच्छा समय भी हो सकता है

  • टेक्स्ट से Unicode में बदलाव, 32-bit से 64-bit में बदलाव, Intel से ARM में बदलाव, Y2K—इन सबको याद कर सकते हैं
    No-GIL कहीं छोटा बदलाव है, और बिना radical breakage के वही migration path अपना सकता है
    अगर कुछ टूटता भी है, तो ऐसे मामलों को handle करने का well-defined तरीका होगा
    हम वैसे भी उन transitions से बच निकले, और आगे बढ़ते देखना अच्छा है
    यह उन और क्षेत्रों को खोलेगा जिन्हें अब तक असंभव माना जाता था
    शुरुआती Swift ने जो एक काम अच्छा किया था, वह यह था कि उसने breaking changes को अपने promise में शामिल किया था, और सबको अपनी स्थिति पता थी और वे अच्छी तरह adapt हुए
    कभी-कभी चाहता हूँ कि Python भी वही रास्ता चुने

    • यह थोड़ा अलग है
      32-bit से 64-bit, ARM, और Y2K—इन सबमें यह test किया जा सकता था कि चीज़ काम करती है या नहीं
      बेशक tests किसी failure case को cover न करें, लेकिन जो tests किए गए वे deterministic होते हैं
      लेकिन यहाँ, आप कितना भी test करें, जवाब यही है: “या तो सही है, या अभी सही race condition को hit नहीं किया है”
    • मुझे migration की कठिनाई की चिंता नहीं है, बल्कि चिंता यह है कि final state वास्तव में अभी से भी खराब हो सकती है
    • टेक्स्ट से Unicode में जाना Python के लिए खास तौर पर बड़ी समस्या थी

  • वे साफ कहते हैं कि वे Python 3 transition scenario दोहराना नहीं चाहते, लेकिन मौजूदा approach भी डरावने ढंग से उसी रास्ते के करीब दिखती है
    बहुत कुछ Python community और distribution channels पर निर्भर है
    community समय पर adopt न कर पाए, या Ubuntu, Fedora, Anaconda जैसे distributions जल्दबाज़ी में आगे निकल जाएँ—दोनों हो सकते हैं
    अभी निश्चित रूप से कहना जल्दबाज़ी होगी, लेकिन ऐसे scenario से बचने के लिए Steering Council के पास असल में कितनी control है, इस पर सवाल है

    • कहा गया है कि No-GIL उपलब्ध होने के 5 साल बाद वे चाहते हैं कि वही अकेला build mode बने, लेकिन यह बहुत लंबा भी है और बहुत छोटा भी
      Python के दो modes होने के लिए 5 साल बहुत लंबा समय है
      आधा दशक दोनों modes को status quo की तरह जमाने के लिए काफी है, और उसके बाद भी पुराने Stack Overflow posts बने रहेंगे
      मैं आशावादी नहीं हूँ कि 5 साल, 10 साल की uncertainty और breakage में नहीं बदलेंगे
      उल्टा, 5 साल शायद इतना भी कम हो सकता है कि सारे C code को निकालकर ठीक किया जाए, test किया जाए और उसे mature कहा जा सके
    • यह 2to3 situation जैसा होगा
      support का वादा करने वाली कंपनियाँ कुछ projects को mechanically convert करेंगी, और असली developers को परेशान कर सकती हैं या fork की धमकी दे सकती हैं
      bugs को असल unpaid developers कई सालों में polish करेंगे
      लेकिन Python को किसी “success” की ज़रूरत है, और यह अच्छा PR phrase बनता है
      Python world में correctness शायद उतनी important नहीं लगती
    • 2-to-3 में, बिना खास वजह के टूटने वाले major version transition का कार्ड खर्च कर दिया गया, और अब बड़े बदलाव के सामने कहा जा रहा है कि “यह 2-to-3 जैसा नहीं होगा”
      उस history की वजह से ऐसा लगता है कि वे एक और major transition की ओर बढ़ने के बजाय CPython 3 के अंदर दो execution modes बनाए रखना चाहते हैं

  • अच्छा है कि वे इस बात को लेकर बहुत conscious हैं कि यह आसानी से Python 4 disaster बन सकता है
    yes-GIL behavior पर accidental असर न पड़े, इसके लिए बेहद सावधान रहना होगा
    अगर किसी तरह का emulated GIL असली GIL जैसा बिल्कुल नहीं हुआ, तो हर तरह के अजीब cases संभव हैं

    • 2 -> 3 से अलग होने के लिए अब तक मैंने सिर्फ दो कारण देखे हैं
      पहला, वे नहीं चाहते कि ऐसा हो
      दूसरा, अगर ऐसा हुआ तो वे जल्दी हार मान लेंगे
      दोनों important हैं, लेकिन लगता है कि “और हम इसे इस तरह हासिल करेंगे” वाला महत्वपूर्ण तीसरा हिस्सा गायब है
    • मुझे यकीन है कि intent अच्छा है, लेकिन पक्का नहीं कि इससे बचा जा सकेगा
      वे पहले ही कह रहे हैं कि GIL और No-GIL 5 साल से ज्यादा साथ रह सकते हैं
      tool makers के लिए इसका मतलब है कि कम-से-कम अगले 5 साल तक cost दोगुनी होगी
      क्योंकि लोग, चाहे productive हों या experimental, दोनों modes में tools इस्तेमाल करना चाहेंगे

  • GIL का मतलब Global Interpreter Lock है
    अच्छी explanation यहाँ है: https://realpython.com/python-gil/

  • इसमें दो बड़ी समस्याएँ हैं
    पहली, कुछ improvements backward compatibility तोड़ने लायक होते हैं और GIL removal ऐसा ही improvement है
    Python 3 के changes इसके लायक थे या नहीं, इस पर debate हो सकती है, और print का function बनना खास तौर पर valuable नहीं लगता
    हालांकि 2-to-3 transition को एक loud minority ने कुछ हद तक बढ़ा-चढ़ाकर बताया, और 5 से ज्यादा codebases को 2 से 3 में migrate करने के अपने experience में, ज्यादातर में समस्या कम थी
    सबसे बड़ी समस्या वे codebases थे जहाँ पुराने developers हर चीज़ के लिए libraries खींच लाए थे और वह abandoned libraries का ढेर बन गया था; ऐसा code core language compatibility न तोड़े तब भी समस्याओं से जूझता है
    जवाब यह नहीं है कि language को हमेशा compatibility न तोड़ने के लिए मजबूर किया जाए, बल्कि यह है कि पूरे pip को उठा लाना sustainable strategy होगा, ऐसी उम्मीद न की जाए
    अभी Steering Council पर loud minority की इतनी आलोचना हुई है कि वह breaking changes से डरती है
    लेकिन GIL removal Python के काम करने के तरीके का इतना fundamental हिस्सा है कि इसे breaking change होना ही चाहिए, और इसे मानकर transition plan बनाना बेहतर है; users से डरकर सच स्वीकार न करते हुए इसे non-breaking बनाने की असंभव कोशिश करना खराब idea है
    Python 3.11 में भी मेरा codebase टूटा था और fix मुश्किल नहीं था, लेकिन यह हो सकता है—इस बारे में communication बेहतर होती तो अच्छा था
    दूसरी, ज्यादा fundamental problem यह है कि Python की कई दूसरी features GIL के इर्द-गिर्द बनी हैं
    खासकर asynchronous paradigm GIL की वजह से बहुत मायने रखता है, लेकिन अगर GIL न होता, तो hindsight में Erlang-style send/recv actor model कहीं बेहतर दिशा होती
    इसे पलटना मुश्किल है, और ऐसा लगता है कि Python उन features के कम cohesive collection की ओर धकेला जा रहा है जो आपस में ठीक से fit नहीं होते, इसलिए यह बहुत देर से और बहुत कम किया जा रहा है

  • Python के core developers और Steering Council का धन्यवाद, और Python, Java और C के साथ मेरी पसंदीदा भाषाओं में से एक है
    Python में असली multithreading का मैं बहुत स्वागत करता हूँ
    Project के हिसाब से मैं multiprocessing और multithreading दोनों इस्तेमाल कर रहा हूँ; multiprocessing का उदाहरण [0] में है, और I/O-heavy कामों के लिए Python Threads इस्तेमाल करने का उदाहरण [1] में है
    लेकिन असली threads इस्तेमाल करना कहीं ज़्यादा efficient होगा
    Threads arbitrary मात्रा में data को एक single atomic और लगभग तुरंत operation के रूप में भेज और प्राप्त कर सकते हैं, लेकिन local loopback interface या multiprocessing, pipes के जरिए यह संभव नहीं है
    मैं एक multithreading architecture पर काम कर रहा हूँ जिसे मैं “three tier multithreading architecture” कहता हूँ
    https://github.com/samsquire/three-tier-multithreaded-archit...
    लक्ष्य एक बेहद scalable और high-performance server है, लेकिन शायद Python उस काम के लिए सही tool न हो
    [0]: https://news.ycombinator.com/item?id=36897054 multiprocessing के इस्तेमाल की व्याख्या
    [1]: https://devops-pipeline.com/ multithreading के इस्तेमाल का उदाहरण