Python की असली सुपरपावर
(youtu.be)यह PYCON UK 2025 में Hynek Schlawack द्वारा दिए गए "Python की असली सुपरपावर" keynote का सार है।
वक्ता ने प्रस्तुति शुरू करने से पहले अपने करियर का संक्षिप्त परिचय दिया और खास तौर पर PyCon कम्युनिटी में 14 वर्षों तक सक्रिय रहते हुए अनुभव की गई "नफ़रत भरी दोस्ती" का ज़िक्र किया।
Python 2 से 3 में बदलाव (The Python 2 to 3 Migration)
- पृष्ठभूमि: Python 3.0 पहली बार 2008 में जारी हुआ था, और यह आम उपयोग के लिए नहीं बल्कि Python के लक्ष्यों को दिखाने और feedback लेने के लिए था। Python 3.2 से इसका उपयोग सुझाया जाने लगा।
- मुख्य बदलाव:
- string handling: Python 3 ने string के default type को machine-friendly bytes से human-friendly Unicode में बदल दिया।
- implicit behavior हटाना: Python 2 में संभव कई implicit behaviors, जैसे string और number की तुलना, जिन पर developers अनजाने में निर्भर हो जाते थे, हटा दिए गए। ये debug करने में मुश्किल bugs पैदा करते थे।
- internationalization में सुधार: Python 2 codebase Unicode decode errors से भरे रहते थे, और Python 3 ने इसे बेहतर बनाकर भाषा को अधिक international बनाया।
- बदलाव की कठिनाइयाँ:
- community cost: पूरे ecosystem को Python 3 पर port करने में बहुत बड़ी लागत लगी। बहुत सारे software को port करना पड़ा, और उस समय test coverage भी आम नहीं थी।
- mixed codebase development: Python 2 और Python 3 दोनों पर चलने वाले hybrid codebase लिखने के तरीके पर सहमति 2012 में Python 3.3 आने के बाद ही बनी।
- language moratorium: Python 3.0 से 3.3 के बीच लगभग कोई नई features नहीं जोड़ी गईं, इसलिए developers के पास Python 3 में जाने की प्रेरणा कम थी।
- अनिश्चितता: यह स्पष्ट नहीं था कि Python 3 dominant version बनेगा भी या नहीं; Perl 6 जैसे उदाहरणों की तरह इसके असफल होने की आशंका भी थी।
- Python के टिके रहने के कारण:
- नए users का आना: Python में नए users का प्रवाह, दूसरे languages (Go, Rust आदि) के बढ़ने के दौर में भी, उससे दूर जाने वालों से अधिक था।
- scientific और engineering community: वैज्ञानिक और इंजीनियर लंबे समय से Python का उपयोग कर रहे थे, और 2010 के दशक के मध्य से data science में इसकी लोकप्रियता तेज़ी से बढ़ी। आज Python users में आधे से अधिक लोग data exploration और processing के लिए Python का उपयोग करते हैं।
- मौजूदा ecosystem: NumPy जैसी मजबूत scientific computing libraries का ecosystem पहले से मौजूद था।
- अन्य compiled languages के साथ आसान interaction: Python, दूसरी compiled languages के साथ आसानी से interact कर सकता है, इसलिए यह C, C++, Fortran, Rust में लिखे high-performance components को जोड़ने वाले "glue" की भूमिका निभा सकता है।
- exploratory programming: interactive shell (REPL) और Jupyter Notebook जैसे tools के कारण Python exploratory programming के लिए बहुत उपयुक्त है।
- graduality: Python अलग-अलग स्तर की rigor प्रदान करता है। developers experiment चरण में लचीले ढंग से काम कर सकते हैं, और production में type hints, linter, tests जैसे tools से कठोरता बढ़ा सकते हैं। इसी तरह Python को Jupyter Notebook से शुरू करके web service तक फैलाया जा सकता है।
Python की असली सुपरपावर: graduality
- Python सिर्फ low entry barrier नहीं देता, बल्कि कई high ceilings भी देता है, जिससे users अपनी ज़रूरत के हिसाब से इसे लचीले ढंग से इस्तेमाल कर सकते हैं।
- graduality के दो पहलू:
- सकारात्मक पक्ष: users अपनी पसंद के अनुसार rigor और complexity का स्तर चुन सकते हैं। उदाहरण के लिए, script लिखते समय type hints के बिना स्वतंत्र रूप से coding की जा सकती है, जबकि बड़े applications में सख्त type checking लागू की जा सकती है।
- नकारात्मक पक्ष: किसी system में special cases या exceptions जोड़ने से short term में individual users को सुविधा मिलती है, लेकिन long term में पूरे system की complexity बढ़ जाती है। "आसान" हमेशा "सरल" नहीं होता — यह बात Python के packaging तरीके में दिखती है।
packaging समस्या का उदाहरण (Packaging Problem Example)
- Python applications को संरचित करने के दो तरीके हैं: 'ad hoc' तरीका और 'package' तरीका। package तरीका अधिक स्पष्ट रूप से परिभाषित है और tooling built-in है, लेकिन ऐतिहासिक कारणों से ad hoc तरीका भी अब तक support किया जाता है।
- इसके कारण
sys.pathजैसी समस्याएँ समझना कठिन हो जाता है, औरpip install --userजैसी सुविधाएँ global namespace में समस्याएँ पैदा करके debugging को कठिन बनाती हैं। - UV जैसे नए tools ने शुरुआत में सिर्फ package तरीका support किया, लेकिन अंततः ad hoc projects को भी support करना पड़ा, जिससे complexity बढ़ी।
- ऐसी "attractive nuisance" चीज़ें short term में सुविधा देती हैं, लेकिन long term में कम्युनिटी पर बड़ा cost डालती हैं।
software architecture
- वे इस बात की ओर इशारा करते हैं कि Python community में software architecture पर चर्चा की कमी है, और इसका कारण "enterprise patterns" के प्रति अरुचि तथा "Java बन जाने के डर" को बताते हैं।
- ज़रूरत: जटिल software systems को बनाने और maintain करने के लिए modules, layers और interactions को व्यवस्थित और प्रबंधित करने वाली software architecture पर चर्चा महत्वपूर्ण है।
- समाधान:
- Python community को "pythonic" या "unpythonic" जैसे शब्दों पर बातचीत समाप्त करने से बचना चाहिए।
- दूसरी language communities की best practices (जैसे domain-driven design) को सीखना और अपनाना चाहिए।
- अधिक लोगों को software architecture से जुड़ा ज्ञान साझा करना चाहिए, संबंधित content बनाना चाहिए, और solutions पर ध्यान देना चाहिए।
निष्कर्ष (Conclusion)
- Python को लेकर असुरक्षित होने के बजाय, Python लिखने के विभिन्न तरीकों को अपनाना चाहिए।
- नए styles और tools आज़माकर अपनी सोच का दायरा बढ़ाना चाहिए।
- options की कीमत होती है, इसलिए किसी feature का पूरी community पर क्या असर होगा, इसे सावधानी से सोचना चाहिए।
- सरल चीज़ों को आसान बनाने के साथ-साथ, जटिल चीज़ों को संभव बनाने पर भी अधिक मेहनत करनी चाहिए।
- software architecture पर अधिक बातचीत होनी चाहिए, और Python को बेहतर भविष्य की ओर ले जाने के लिए कट्टर सोच पर सवाल उठाने चाहिए।
यह प्रस्तुति Python community के अतीत, वर्तमान और भविष्य को समेटते हुए, भाषा की असली ताकत "graduality" पर ज़ोर देती है, और community के सामने मौजूद चुनौतियों व उन्हें पार करने के लिए आवश्यक सांस्कृतिक बदलावों पर गहरी अंतर्दृष्टि देती है।
वीडियो देखने के लिए यह लिंक देखें: https://youtu.be/gDvwRpl9erE
3 टिप्पणियां
अगर
uv-स्टाइल का आधुनिक package manager standard बन जाए, तो काफ़ी सुविधा हो जाएगी, लेकिन शायद यह मुश्किल ही होगा..स्नातक की पढ़ाई के शुरुआती दौर में मुश्किल से python 2 ज़्यादा mainstream था, लेकिन ग्रेजुएशन तक पहुँचते-पहुँचते याद है कि सब लोग python 3 पर शिफ्ट हो गए थे।
अगर आप coding को पेशे के तौर पर करते हैं, तो चाहे आपका मुख्य ज़ोर Python पर ही क्यों न हो, ज़्यादातर मामलों में आप कम-से-कम एक या उससे ज़्यादा दूसरी भाषाएँ भी जानते होंगे।
मुझे समझ नहीं आता कि Python को बेहतर बनाया जाना चाहिए कहते हुए दूसरी भाषाओं के features या characteristics को बार-बार उसमें क्यों लाने की कोशिश की जाती है।
ऐसा लगता है कि लोग इस बात को नज़रअंदाज़ कर रहे हैं कि Python की जो कमियाँ मानी जाती हैं, वही उसकी लोकप्रियता की वजह भी रही हैं।
धीरे-धीरे Python अजीब तरह से ज़्यादा complex और पेचीदा होता जा रहा है।
लगता है जैसे Python इस्तेमाल करने का फायदा ही कम होता जा रहा है।
Python को Java जैसा बनाने की कोशिश करने के बजाय, ज़रूरत के हिसाब से सीधे Java इस्तेमाल कर लें तो क्या बुरा है।
Java नहीं तो Kotlin है, Scala भी है।
फिर भी, मुझे नहीं लगता कि Python खत्म होगा।
क्योंकि इतनी आसानी से coding करने देने वाली भाषा practically और कोई है ही नहीं।