पायथन 3 पर विचार

मैं आपका ध्यान जिंजा 2, विर्केजग और फ्लास्क, स्फिंक्स के सह-लेखक और पियर्स एर्मिन रोनचेर के एक अद्भुत लेख की ओर दिलाता हूं। मैंने उनकी रचनाओं के स्रोत कोड को छाँटने में बहुत आनंद लिया और अपने लिए बहुत कुछ सीखा। अर्मिन उत्कृष्ट रूपरेखा लिखते हैं, और कोई और कैसे व्याख्या कर सकता है कि पायथन 2 से पायथन 3 तक संक्रमण क्या है और क्यों इसे लागू करना इतना आसान नहीं है।

पायथन 3 पर विचार

हाल ही में, मुझे अक्सर पायथन राज्य के बारे में विचारों के साथ दौरा किया गया है। 3. पहली नज़र में नहीं, मैं पायथन के साथ प्यार में पड़ गया और जो कोर्स कर रहा है, उससे अधिक खुश हूं। दस साल मेरी जिंदगी अजगर के साथ चलती है। और जबकि यह मेरे जीवन का एक बड़ा हिस्सा है।

मैं आपको पहले से चेतावनी देता हूं: यह एक बहुत ही व्यक्तिगत लेख है। मैंने इस पाठ में एक पूंजी पत्र की सौ प्रतियाँ गिनाईं।

ऐसा इसलिए है क्योंकि मैं पिछले दो वर्षों में प्राप्त किए गए सभी अवसरों के लिए बहुत आभारी हूं: दुनिया की यात्रा करने की क्षमता, लोगों के साथ संवाद और सहयोग की भावना को साझा करना जो नवाचार और खुशहाल लोगों को प्रोत्साहित करने के लिए पाइथन जैसी स्वतंत्र रूप से वितरित परियोजनाओं की अनुमति देता है। पायथन में एक अद्भुत समुदाय है, जिसे मैं अक्सर ज़ोर से कहना भूल जाता हूं।

और दूसरी ओर, हालाँकि मैं पायथन से प्यार करता हूँ और इसके तरीकों और समाधानों पर चर्चा करना पसंद करता हूँ, मैं इस पर समर्पण के बावजूद किसी भी बाध्यता के साथ इस परियोजना से बाध्य नहीं हूँ। जब मैं भाषा के बारे में बैठकों में भाग लेता हूं, तो मुझे तुरंत समझ में आता है कि मेरे प्रस्तावों को शत्रुता क्यों माना जाता है, और मैं खुद अभी भी उस चंचल माना जाता हूं। "वह लगातार शिकायत करता है और कुछ नहीं करता है।" इतना कुछ है कि मैं अजगर में देखना चाहूंगा, लेकिन अंत में, मैं इसका उपयोगकर्ता हूं, डेवलपर नहीं।

जब आप पायथन 3 के बारे में मेरी टिप्पणियों को पढ़ते हैं, तो यह देखते हुए कि इसका पहला संस्करण पहले ही जारी हो चुका है, आपको यह धारणा मिलती है कि मैं इससे नफरत करता हूं और इसे बिल्कुल भी स्विच नहीं करना चाहता। जैसा मैं चाहता हूं, लेकिन उस रूप में नहीं जिस रूप में वह अब है।

मेरे अनुभव को ध्यान में रखते हुए कि लोग लेखों को लिखने के लंबे समय बाद लिंक करते हैं, मुझे लिखने के समय पहले पायथन 3 के साथ स्थिति स्पष्ट करने दें: संस्करण 3.2 जारी किया गया है, अगला संस्करण 3.3 है, और पायथन 2.8 को जारी करने की कोई योजना नहीं है। इसके अलावा, पीईपी है जिसमें यह काले और सफेद रंग में लिखा गया है: कोई रिलीज नहीं होनी चाहिए। पूरी तरह से विकसित होने के कारण, PyPy एक ऐसी परियोजना बनी हुई है जिसकी वास्तुकला बाकी सब चीजों से इतनी दूर है कि कोई भी इसे लंबे समय तक गंभीरता से नहीं लेगा। कई मायनों में, PyPy ऐसे काम करता है जो "मैं नहीं करूंगा" और यह मेरे लिए आश्चर्यजनक है।

हम पायथन का उपयोग क्यों करते हैं?

हम पायथन का उपयोग क्यों कर रहे हैं? यह मुझे लगता है कि यह एक बहुत ही सही सवाल है, जिसे हम शायद ही कभी खुद से पूछें। अजगर में खामियों का एक समूह है, लेकिन मैं इसे वैसे भी उपयोग करता हूं। पार्टी में, इस साल के PyCodeConf सम्मेलन के अंतिम दिन, मैं निक कॉफ़्लान के साथ बहुत चर्चा करने में कामयाब रहा। हम एक समर्थक थे, और इसके लिए, चर्चा बहुत ईमानदारी से हुई। हम इस तथ्य को स्वीकार करने के लिए सहमत हुए कि पायथन एक भाषा के रूप में परिपूर्ण नहीं है, यह काम कुछ खामियों पर जारी है, और यह कि सावधानीपूर्वक विचार करने पर, उनमें से कुछ में कोई बहाना नहीं है। "इससे उपज" पर पीईपी को एक अधिक या कम काम करने वाले रूप देने के लिए एक संदिग्ध डिजाइन (एक जनरेटर के रूप में कोरटाइन) के विकास का एक उदाहरण माना जाता था। लेकिन "उपज से" में अपनाए गए परिवर्तनों के बावजूद, यह सब ग्रीनलेट की सुविधा से बहुत दूर है।

यह बातचीत सम्मेलन के उसी यादगार दिन पर गेरी बर्नार्ड द्वारा दिए गए "बायस्ड ओपिनियन ऑन प्रोग्रामिंग लैंग्वेज" व्याख्यान की निरंतरता थी। हम एक सामान्य दृष्टिकोण के लिए आए थे कि रूबी ब्लॉकों में एक अद्भुत डिजाइन है, लेकिन कई कारणों से यह पायथन (इसकी वर्तमान स्थिति में) में जड़ नहीं लिया होगा।

व्यक्तिगत रूप से, मुझे नहीं लगता कि हम पायथन का उपयोग करते हैं क्योंकि यह एक आदर्श और त्रुटिहीन भाषा है। इसके अलावा, यदि आप समय में वापस जाते हैं और पायथन के पुराने संस्करणों को देखते हैं तो आप देखेंगे कि यह बहुत, बहुत बदसूरत है। आश्चर्य न करें कि अपने शुरुआती वर्षों में, पायथन किसी के द्वारा अप्रभावित रहा।

यह मुझे लगता है कि तब से पायथन द्वारा प्राप्त की गई गुंजाइश को एक बड़ा चमत्कार माना जा सकता है। और इसीलिए, यह मुझे लगता है, हम पायथन का उपयोग करते हैं: इस भाषा का विकास बहुत सहज था, और मूर्त विचार सही थे। प्रारंभिक पायथन भयानक था, इसमें पुनरावृत्तियों की अवधारणा का अभाव था, और इसके अलावा, एक शब्दकोश के माध्यम से पुनरावृति करने के लिए, आपको इसकी सभी कुंजियों की एक मध्यवर्ती सूची बनानी होगी। कुछ बिंदु पर, अपवाद स्ट्रिंग थे; स्ट्रिंग विधियाँ एक ही नाम (स्ट्रिंग) के मॉड्यूल से विधियां नहीं थीं। अपवाद पकड़ने वाला वाक्यविन्यास हमें पायथन 2 के सभी पहलुओं में पीड़ा देता है, और यूनिकोड बहुत देर से और आंशिक रूप से प्रकट हुआ - कभी नहीं।

हालाँकि, वहाँ यह बहुत अधिक था। चलो और दोषपूर्ण, अपने स्वयं के नामस्थानों के साथ मॉड्यूल का विचार अद्भुत था। मल्टीमिथोड्स ^* पर आधारित भाषा संरचना अभी भी काफी हद तक अद्वितीय है। हर दिन हम इस फैसले से लाभान्वित होते हैं, हालांकि हम खुद को इस बारे में रिपोर्ट नहीं देते हैं। इस भाषा ने हमेशा अपना काम ईमानदारी से किया और छिपाया नहीं कि दुभाषिया (ट्रेसबैक, स्टैक फ्रेम, ओपकोड, कोड ऑब्जेक्ट, एस्ट्रो, आदि) में क्या हो रहा है, जो कि गतिशील संरचना के साथ मिलकर, डेवलपर को जल्दी से डिबग करने और आसानी से अप्राप्य होने वाली समस्याओं को हल करने की अनुमति देता है। अन्य भाषाओं में।

इंडेंटेशन सिंटैक्स की अक्सर आलोचना की जाती थी, लेकिन यह देखते हुए कि इस दृष्टिकोण (HAML, CoffeeScript और कई अन्य लोगों के दिमाग में कितनी नई भाषाएं आ रही हैं) यह साबित करती हैं कि इसे मान्यता मिली है।

यहां तक ​​कि जब मैं रेमंड ^* मानक पुस्तकालय के लिए कुछ नया लिखता हूं, तो इससे असहमत हूं, लेकिन इसके मॉड्यूल की गुणवत्ता में थोड़ी भी संदेह नहीं है और यह मुख्य कारणों में से एक है कि मैं पायथन का उपयोग क्यों करता हूं। मैं संग्रह मॉड्यूल या itertools तक पहुँच के बिना पायथन के साथ काम करने की कल्पना नहीं कर सकता।

लेकिन पाइथन को प्यार करने और उसे पहचानने का असली कारण प्रत्येक नए संस्करण की प्रत्याशा थी, जैसे कि एक अधीर बच्चा क्रिसमस का इंतजार कर रहा था। छोटे, मुश्किल से ध्यान देने योग्य सुधारों ने मुझे रोमांचित किया। यहां तक ​​कि एन्यूमरेट फ़ंक्शन के लिए सूचकांक की शुरुआत को इंगित करने की क्षमता ने मुझे नए पायथन रिलीज के लिए आभारी महसूस किया। और यह सब पिछड़ी अनुकूलता को ध्यान में रखते हुए किया गया है।

__Future__ से आयात करना कुछ ऐसी चीज है जिससे हम कभी-कभी बहुत नफरत करते हैं और वास्तव में अपग्रेड आसान और दर्द रहित बना देते हैं। मैं PHP का उपयोग करता था और नई रिलीज़ के बारे में पूरी तरह से खुश नहीं था। PHP में कोई नामस्थान नहीं थे, लेकिन हमेशा नए अंतर्निहित कार्य थे और हर रिलीज़ के साथ मैं वास्तव में नामों में संघर्ष से बचने की उम्मीद करता था (मुझे पता है कि अगर मैं उपसर्ग का उपयोग करता हूं तो मैं उनसे बच सकता था, लेकिन इससे पहले कि विकास की मूल बातें सीख ली गई थीं पर)।

क्या बदल गया है?

यह कैसे हुआ कि मैं नए पायथन रिलीज के लिए तैयार नहीं था? मैं केवल अपने लिए बोल सकता हूं, लेकिन मैंने देखा कि दूसरों ने नई रिलीज के लिए अपना रवैया बदल दिया है।

मैंने कभी नहीं सोचा कि अगले पायथन 2.x के मुख्य डेवलपर्स क्या कर रहे थे।
बेशक, कुछ इतनी अच्छी तरह से सोचा नहीं गया था, उदाहरण के लिए, अमूर्त वर्गों के कार्यान्वयन या उनके शब्दार्थ की विशेषताएं। लेकिन मूल रूप से यह सब उच्च स्तर की कार्यक्षमता की आलोचना के लिए आया था।

पायथन 3 के आगमन के साथ, बाहरी कारक भी दिखाई दिए, जिसके कारण मुझे भाषा के साथ काम करने के लिए अचानक सामान्य दृष्टिकोण को बदलना पड़ा। इससे पहले, मैं लंबे समय तक भाषा की नई विशेषताओं का उपयोग नहीं करता था, हालांकि मुझे इसकी खुशी थी, क्योंकि ज्यादातर पुस्तकालयों में लिखा है। यह सबसे नया और सबसे अच्छा उपयोग करने के लिए एक गलती होगी। वर्क्ज़ुग का कोड अभी भी हैक के साथ crammed है जो इसे पायथन 2.3 में चलने की अनुमति देता है, हालांकि अब न्यूनतम आवश्यकताएं 2.5 संस्करण तक बढ़ गई हैं। मैंने मानक लाइब्रेरी के लिए बगफिक्स को कोड में छोड़ दिया, क्योंकि कुछ निर्माता (कुख्यात Apple) दुभाषिया को कभी भी अपडेट नहीं करते हैं जब तक कि इसमें कोई महत्वपूर्ण भेद्यता नहीं मिलती।

यह सब अजगर 3 के साथ असंभव है। इसके साथ, सब कुछ विकास में 2.x या 3.x के लिए बदल जाता है। और कोई मध्य निर्णय अपेक्षित नहीं है।

पायथन 3 की घोषणा के बाद, गुइडो ने हमेशा 2to3 के बारे में खुशी से बात की और यह कैसे पोर्टिंग को आसान बना देगा। लेकिन यह पता चला कि 2to3 सबसे बुरी चीज है जो पायथन को हो सकती है।

जब मैं 2to3 का उपयोग करके जिनजा 2 को पोर्ट कर रहा था, तो मुझे बड़ी मुश्किलों का अनुभव हुआ, जिसका मुझे बाद में बहुत पछतावा हुआ। इसके अलावा, JSON जिनजा परियोजना में, मैंने सही तरीके से काम करने के लिए 2to3 के लिए लिखे गए सभी हैक्स को हटा दिया और फिर कभी इसका उपयोग नहीं करेगा। कई अन्य लोगों की तरह, अब मैं कोड को बनाए रखने के लिए अपनी पूरी कोशिश कर रहा हूं जो संस्करणों 2.x और 3.x दोनों पर काम करता है। तुम पूछते हो क्यों? क्योंकि 2to3 बहुत अस्वास्थ्यकर है, यह खराब तरीके से परीक्षण प्रक्रिया में एकीकृत होता है, यह इस्तेमाल किए गए पायथन 3 के संस्करण पर निर्भर करता है और काले जादू के उपयोग के अलावा बाकी सभी को कॉन्फ़िगर किया जा सकता है। यह एक दर्दनाक प्रक्रिया है जो पुस्तकालयों को लिखने से मिलने वाली सभी खुशियों को नकार देती है। मुझे जिनजा 2 ट्रिम करना पसंद था, लेकिन पायथन 3 पर बंदरगाह तैयार होने के कारण ऐसा करना बंद कर दिया, क्योंकि मुझे इसमें कुछ टूटने का डर था।

अब, एक साझा कोडबेस का विचार इस तथ्य पर निर्भर करता है कि मुझे पायथन का संस्करण 2.5 तक समर्थन करना है।

पायथन 3 के कारण हुए परिवर्तनों ने हमारे सभी कोड को अनुपयोगी बना दिया, जो इसे फिर से लिखने और इसे अपग्रेड करने के लिए कोई बहाना नहीं है। मेरी गहरी व्यक्तिपरक राय में, अजगर 3.3 / 3.4 अधिक होना चाहिए, जैसे पायथन 2 और अजगर 2.8 पायथन 3 के करीब होना चाहिए। ऐसा हुआ है कि प्रोग्रामिंग भाषाओं की दुनिया में पायथन 3 एक्सएचटीएमएल है। यह बदलने की कोशिश कर रहा है के साथ असंगत है, और बदले में व्यावहारिक रूप से कुछ भी नहीं प्रदान करता है सिवाय इसके कि यह अधिक "सही" है।

यूनिकोड के बारे में थोड़ा सा

जाहिर है, पायथन 3 में सबसे बड़ा बदलाव यूनिकोड हैंडलिंग था। ऐसा प्रतीत हो सकता है कि सभी के लिए और सभी के लिए यूनिकोड का रोपण एक आशीर्वाद है। और फिर भी, यह गुलाबी चश्मे के माध्यम से दुनिया का एक दृश्य है, क्योंकि वास्तविक दुनिया में हमें न केवल बाइट्स और यूनिकोड के साथ सामना करना पड़ता है, बल्कि एक प्रसिद्ध एन्कोडिंग के साथ तार भी होता है। सबसे खराब, कई मायनों में, पायथन 3 प्रोग्रामिंग भाषाओं की दुनिया में फिशर प्राइस ^* का एक प्रकार बन गया है। कुछ सुविधाओं को हटा दिया गया है कर्नेल डेवलपर्स ने महसूस किया कि वे "आसानी से कट सकते हैं।" और यह सब व्यापक रूप से इस्तेमाल की जाने वाली कार्यक्षमता को हटाने की कीमत पर दिया गया था।

यहां एक विशिष्ट उदाहरण है: 3.x में कोडेक्स के साथ संचालन वर्तमान में यूनिकोड <-> बाइट्स रूपांतरण तक सीमित हैं। कोई बाइट्स <-> बाइट्स या यूनिकोड <-> यूनिकोड। यह उचित लगता है, लेकिन करीब से देखने पर आप देखेंगे कि यह रिमोट फंक्शनलिटी बस वही है जो महत्वपूर्ण है।

पायथन 2 में कोडेक सिस्टम की सबसे उल्लेखनीय विशेषताओं में से एक यह था कि इसे भारी संख्या में एन्कोडिंग और एल्गोरिदम के साथ विविध कार्यों के लिए बनाया गया था। आप तारों को एन्कोड करने और डिकोड करने के लिए एक कोडेक का उपयोग कर सकते हैं, और आप कोडेक को किसी ऑब्जेक्ट के लिए भी पूछ सकते हैं जो स्ट्रीम और अन्य अपूर्ण डेटा पर संचालन प्रदान करता है। और फिर भी, कोडेक सिस्टम सामग्री और हस्तांतरण एन्कोडिंग के साथ समान रूप से अच्छी तरह से काम करता है। यह एक नया कोडेक लिखने और इसे पंजीकृत करने के लायक था, क्योंकि सिस्टम के प्रत्येक भाग ने इसके बारे में स्वचालित रूप से सीखा।

जो कोई भी पायथन में एक HTTP पुस्तकालय लिखने का उपक्रम करता है, उसे यह जानकर खुशी हुई कि कोडेक्स का उपयोग न केवल UTF-8 (वास्तविक चरित्र एन्कोडिंग) को डिकोड करने के लिए किया जा सकता है, बल्कि उदाहरण के लिए gzip (संपीड़न एल्गोरिथ्म) के लिए भी किया जा सकता है। यह न केवल स्ट्रिंग्स पर लागू होता है, बल्कि जनरेटर या फ़ाइल ऑब्जेक्ट्स पर भी लागू होता है, जब तक कि निश्चित रूप से आप नहीं जानते कि उनका उपयोग कैसे करें।

फिलहाल, पायथन 3 में, यह सब बस काम नहीं करता है। उन्होंने न केवल स्ट्रिंग ऑब्जेक्ट से इन कार्यों को हटा दिया, बल्कि बाइट - बाइट एन्कोडिंग को भी हटा दिया, बदले में कुछ भी नहीं छोड़ा। अगर मुझसे गलती नहीं हुई है, तो समस्या को पहचानने में 3 साल लग गए और उपरोक्त कार्यक्षमता के 3.3 के बारे में चर्चा शुरू करने के लिए।

इसके बाद, यूनिकोड को धक्का दिया गया जहां वह बिल्कुल भी नहीं था। ऐसी जगहों में फाइल सिस्टम लेयर और URL मॉड्यूल शामिल हैं। और फिर भी, 70 के दशक में रहने वाले एक प्रोग्रामर के दृष्टिकोण से यूनिकोड कार्यक्षमता का एक गुच्छा लिखा गया था।

यूनिक्स फ़ाइल सिस्टम बाइट-आधारित हैं। तो यह व्यवस्था है और इसके बारे में कुछ भी नहीं किया जा सकता है। स्वाभाविक रूप से, इसे बदलना बहुत अच्छा होगा, जो कि मौजूदा कोड को तोड़े बिना वास्तव में असंभव है। और सभी क्योंकि एन्कोडिंग को बदलना यूनिकोड-उन्मुख फ़ाइल सिस्टम के लिए आवश्यक एक छोटा सा हिस्सा है। इसके अलावा, पहले से किए गए सामान्यीकरण के साथ सामान्यीकरण रूपों और भंडारण सूचनाओं के प्रश्न खुले रहते हैं। यदि बाइटस्ट्रिंग प्रकार पायथन 3 में रहता है, तो इन समस्याओं से बचा जा सकता था। हालांकि, यह मौजूद नहीं है और इसके प्रतिस्थापन, प्रकार बाइट, व्यवहार के तरीके का व्यवहार नहीं करता है। यह बाइट डेटा का उपयोग करने वाले लोगों को दंडित करने के लिए लिखे गए डेटा प्रकार की तरह व्यवहार करता है जो एक साथ एक स्ट्रिंग के रूप में मौजूद है। यह एक उपकरण के रूप में विकसित नहीं लगता है जिसके साथ प्रोग्रामर इन समस्याओं को हल कर सकते हैं। समस्याएं जो वास्तविक से अधिक हैं।

इसलिए, यदि आप पायथन 3 से एक फ़ाइल सिस्टम के साथ काम कर रहे हैं, तो सरोगेट जोड़े और परिरक्षण के साथ एक नए एन्कोडिंग की उपस्थिति के बावजूद अजीब भावना आपको नहीं छोड़ेगी। यह एक दर्दनाक प्रक्रिया है, दर्दनाक है क्योंकि इस बेडलैम को रेक करने के लिए कोई उपकरण नहीं है। पायथन 3 तरह के मोड़ आपके लिए, "बडी, आपका यूनिकोड फ़ाइल सिस्टम अभी से है," लेकिन यह इस बात की व्याख्या नहीं करता है कि आपको इस गड़बड़ी को खत्म करने की आवश्यकता है। यह भी स्पष्ट नहीं करता है कि फ़ाइल सिस्टम वास्तव में यूनिकोड का समर्थन करता है, या क्या पायथन इस समर्थन का समर्थन करता है। यह सामान्यीकरण के बारे में विवरण का खुलासा नहीं करता है या फ़ाइल नामों की तुलना कैसे की जानी चाहिए।

यह प्रयोगशाला में काम करता है, लेकिन क्षेत्र में टूट जाता है। ऐसा हुआ कि मेरे पोस्ता में एक अमेरिकी कीबोर्ड लेआउट, एक अमेरिकी लोकेल है, और लगभग सब कुछ अमेरिकी है, सिवाय इसके कि तिथियां और संख्याएं अलग-अलग स्वरूपित हैं। इस सब के परिणामस्वरूप (और जैसा कि मैं मानती हूं कि मैंने अपने पॉप्पी को टाइगर के समय से अपग्रेड किया है), मेरे पास निम्न स्थिति थी: मेरे रिमोट सर्वर पर जाकर, मैंने लोकेल को स्ट्रिंग मान "पोसिक्स" पर सेट कर दिया। आप पूछते हैं, "पॉसिक्स" किस तरह का है? और नरक जानता है। इसलिए पायथन, मैं के रूप में एक ही अज्ञानता में होने के नाते, "ANSI_X3.4_1968" के साथ काम करने का फैसला किया। इस यादगार दिन पर, मुझे पता चला कि ASCII के कई नाम हैं। यह पता चला कि यह ASCII नामों में से एक है। और यहां आप जाते हैं, मेरे दूरस्थ पायथन इंटरप्रेटर ने कुटिल रूप से अंतर्राष्ट्रीय फ़ाइल नामों के साथ एक निर्देशिका की सामग्री प्रदर्शित की। वे वहां कैसे पहुंचे? मैंने उनके मूल नामों के साथ विकिपीडिया लेखों को फेंक दिया। मैंने पायथन 3.1 का उपयोग करके ऐसा किया, जो अपवादों को फेंकने या किसी हैक्स का उपयोग करने के बजाय फाइलों के साथ क्या हो रहा था, इस बारे में चुप था।

लेकिन फाइल सिस्टम के साथ खराबी सिर्फ फूल हैं। डिफ़ॉल्ट फ़ाइल एन्कोडिंग सेट करने के लिए पायथन पर्यावरण चर (जहां आपको पता है, यह कचरे से भरा है) का उपयोग करता है। सम्मेलन के दौरान, मैंने कुछ दर्शकों को पायथन 3 में पाठ फ़ाइलों के लिए डिफ़ॉल्ट रूप से उपयोग किए गए एन्कोडिंग का अनुमान लगाने के लिए कहा। इस छोटे से नमूने का 90% से अधिक यह सुनिश्चित था कि यह यूटीएफ -8 था। और नहीं! यह प्लेटफ़ॉर्म के स्थान के आधार पर स्थापित किया गया है। जैसा कि मैंने आपको बताया, 70 के दशक से शुभकामनाएं।

मज़े के लिए, मैंने उन दोनों सर्वरों में लॉग इन किया जिन्हें मैं नियंत्रित करता हूं और पाया कि उनमें से एक में कंसोल के माध्यम से लॉग इन करते समय एक लैटिन 1 एन्कोडिंग था, जो रूट के तहत ssh के माध्यम से लॉग इन करते समय लैटिन 15 पर स्विच हो जाता है, और अगर मैं अपने उपयोगकर्ता खाते का उपयोग कर लॉग इन करता हूं तो UTF-8। धिक्कार है मनोरंजक, लेकिन केवल खुद को दोष देने के लिए। मुझे कोई संदेह नहीं है कि मैं केवल एक ही नहीं हूँ जिसका सर्वर जादुई रूप से दिए गए एन्कोडिंग को स्विच करता है, डिफ़ॉल्ट रूप से, SSH लॉगिन के माध्यम से लोकेल सेटिंग्स भेजता है।

मैं यहाँ इस बारे में क्यों लिख रहा हूँ? हां, क्योंकि मुझे बार-बार यह साबित करना है कि पायथन 3 में यूनिकोड का समर्थन मुझे पायथन 2 की तुलना में बहुत अधिक परेशानी देता है।

यूनिकोड एन्कोडिंग और डिकोडिंग किसी के भी रास्ते में नहीं आती है जो ज़ेन पायथन 2 का अनुसरण उस "स्पष्ट से बेहतर है।" "बाइट्स आते हैं, यूनिकोड बाहर निकलता है" - यह है कि अन्य सेवाओं के साथ काम करने वाले अनुप्रयोगों के टुकड़े कैसे काम करते हैं। यह समझाया जा सकता है। आप इसे डॉक्यूमेंट करके अच्छी तरह समझा सकते हैं। आप इस बात पर जोर देते हैं कि यूनिकोड के रूप में आंतरिक पाठ प्रसंस्करण के कारण हैं। आप उपयोगकर्ता को बताते हैं कि हमारे आसपास की दुनिया कठोर है और बाइट्स पर आधारित है, इसलिए आपको इस दुनिया के साथ संवाद करने के लिए एनकोड और डीकोड करना होगा। यह अवधारणा उपयोगकर्ता के लिए नई हो सकती है। लेकिन आपको बस सही शब्दों को ढूंढना है और सब कुछ अच्छी तरह से पेंट करना है, कैसे एक सिरदर्द कम हो जाएगा।

मैं इस बारे में इतने आत्मविश्वास से क्यों बात कर रहा हूं? क्योंकि 2006 से, मेरे सभी कार्यक्रम यूनिकोड उपयोगकर्ताओं को आगे बढ़ा रहे हैं, और यूनिकोड के बारे में प्रश्नों की संख्या की तुलना पैकेज या आयात प्रणाली के साथ काम करने के बारे में प्रश्नों की सफलता से नहीं की जा सकती। Distutils2 के साथ भी, पायथन के दायरे में, पैकेज यूनिकोड की तुलना में बहुत बड़ी समस्या बने हुए हैं।

घटनाओं के एक प्राकृतिक विकास से दूर: यूनिकोड को पायथन 3 उपयोगकर्ता से दूर छुपाना। लेकिन लोगों के लिए यह कल्पना करना मुश्किल हो गया कि यह सब कैसे काम करता है। क्या हमें एक प्राथमिकता निहित व्यवहार की आवश्यकता है? मुझे इतना यकीन नहीं है।

ज़रूर, पायथन 3 अभी सही रास्ते पर है। मैंने पाया कि अधिक से अधिक चर्चा कुछ बाइट एपीआई वापस करने के बारे में है। मेरा भोला विचार तीसरे प्रकार के स्ट्रिंग का विचार था पायथन 3, जिसे एस्ट्र, या ऐसा कुछ कहा जाता है। यह बिल्कुल Python 2, str बाइट्स की तरह काम करेगा और स्ट्रिंग APIs का एक ही सेट होगा। हालाँकि, इसमें एन्कोडिंग जानकारी भी शामिल होगी जिसका उपयोग यूनिकोड स्ट्रिंग के लिए पारदर्शी रूप से डीकोड करने या बाइट ऑब्जेक्ट में करने के लिए किया जाएगा। यह प्रकार एक पवित्र कब्र होगी जो पोर्टिंग की सुविधा प्रदान कर सकती है।

लेकिन यह वहाँ नहीं है, और पायथन दुभाषिया को एक और प्रकार के स्ट्रिंग के लिए आरक्षित के साथ डिज़ाइन नहीं किया गया था।

हमने उनकी दुनिया को नष्ट कर दिया

निक ने बात की कि पायथन कोर के डेवलपर्स ने वेब प्रोग्रामरों की दुनिया को कैसे नष्ट कर दिया। अब तक, विनाश का विस्तार होता है जहां पायथन की पिछड़ी असंगतता समाप्त होती है। लेकिन हमारी दुनिया अन्य डेवलपर्स की दुनिया से ज्यादा नष्ट नहीं हुई। आखिर हमारी एक दुनिया है। नेटवर्क एन्क्रिप्टेड बाइट्स पर आधारित है, लेकिन यह मुख्य रूप से निम्न-स्तर के प्रोटोकॉल की चिंता करता है। बाइट भाषा में एनकोडिंग के साथ निचले स्तर पर मौजूद अधिकांश के साथ संचार।

हालांकि, मुख्य परिवर्तनों ने सोचने के तरीके को प्रभावित किया, जिसकी आवश्यकता इन स्तरों पर काम करते समय होती है।पायथन 2 ने निचले स्तरों के साथ संवाद करने के लिए बहुत बार यूनिकोड वस्तुओं का उपयोग किया। यदि आवश्यक हो, तो वस्तुओं को बाइट्स और इसके विपरीत में एन्कोड किया गया था। हमारे लिए एक सुखद दुष्प्रभाव, उदाहरण के लिए, शुरुआती चरणों में डेटा को एन्कोडिंग और डिकोड करके कुछ कार्यों को गति देने की क्षमता थी और उन्हें यूनिकोड समझने वाले चैनल में स्थानांतरित करना था। कई मायनों में, यह क्रमबद्ध मॉड्यूल को कर्नेल में कार्य करने की अनुमति देता है। उदाहरण के लिए, अचार, बाइट्स और यूनिकोड दोनों का समर्थन करने वाली धाराओं के साथ संचार करता है। कुछ हद तक वही सरलजन्य कहा जा सकता है। और इसलिए, पायथन 3 दिखाई देता है जिसमें अचानक आपको यूनिकोड और बाइट धाराओं को अलग करने की आवश्यकता होती है। कई एपीआई पायथन 3 के पथ पर नहीं बचेंगे, उनके इंटरफेस में बड़े बदलाव के बिना।

हां, यह अधिक सही दृष्टिकोण है, लेकिन वास्तव में उसे अब कोई लाभ नहीं है, सिवाय इसके कि वह अधिक सही है।

पायथन 3 में I / O कार्यक्षमता के साथ काम करते समय, मैंने सुनिश्चित किया कि यह बहुत अच्छा था। लेकिन वास्तव में, यह तुलना नहीं की जा सकती है कि पायथन 2 ने कैसे काम किया है। ऐसा लग सकता है कि मेरे पास बहुत पूर्वाग्रह हैं, क्योंकि मैंने पायथन 2 के साथ बहुत काम किया और पायथन 3 के साथ इतना कम, हालांकि, अधिक कोड लिखना समान कार्यात्मक प्राप्त करना खराब रूप माना जाता है। और पायथन 3 के साथ, मुझे यह सब करना होगा, इसके सभी पहलुओं को देखते हुए।

लेकिन पोर्टिंग काम करता है!

बेशक, पायथन 3 में काम करता है। यह साबित हो चुका है, और एक से अधिक बार। लेकिन सिर्फ इसलिए कि कुछ संभव है और सभी परीक्षणों को पास करने का मतलब यह नहीं है कि सब कुछ ठीक हो गया है। मैं विकलांग व्यक्ति हूं और गलतियों का एक समूह हूं। उसी समय, मुझे अपने पसंदीदा एपीआई को चमकाने का प्रयास करने पर गर्व है। कभी-कभी मैं अपने आप को बार-बार कोड का एक टुकड़ा लिखकर इसे और अधिक उपयोगकर्ता के अनुकूल बनाता हूं। फ्लास्क के साथ काम करते समय, मैंने कोर कार्यक्षमता को सम्मानित करने में इतना समय बिताया कि यह जुनून के बारे में बात करना शुरू करने का समय है।

मैं चाहता हूं कि यह पूरी तरह से काम करे। जब मैं एक सामान्य कार्य के लिए एपीआई का उपयोग करता हूं, तो मैं चाहता हूं कि उनके पास पोर्श के डिजाइन के समान उत्कृष्टता का स्तर हो। हां, यह डेवलपर के लिए केवल बाहरी परत है, लेकिन उत्पाद को शुरू से अंत तक अच्छी तरह से विकसित किया जाना चाहिए।

मैं पायथन 3 में अपना कोड "काम" कर सकता हूं और फिर भी मैं इससे नफरत करूंगा। मैं चाहता हूं कि यह काम करे। लेकिन एक ही समय में, अपने या अन्य लोगों के पुस्तकालयों का उपयोग करते हुए, मैं पायथन 3 के साथ वही आनंद प्राप्त करना चाहता हूं जो मुझे पायथन 2 से मिलता है।

Jinja2, उदाहरण के लिए, पायथन 3 में इनपुट / आउटपुट परत का सही ढंग से उपयोग नहीं करता है, क्योंकि रनटाइम पर कार्यान्वयन के बीच स्विच किए बिना 2.x और 3.x पर समान कोड का उपयोग करना असंभव है। अब, द्विआधारी मोड में 2.x और 3.x दोनों में टेम्पलेट खुलते हैं, क्योंकि यह एकमात्र विश्वसनीय दृष्टिकोण है, और उसके बाद, जिन्जा 2 स्वयं इस द्विआधारी धारा से डेटा को डीकोड करता है। दरअसल, यह काम करता है, न्यूलाइन विभाजकों के सामान्यीकरण के लिए धन्यवाद। लेकिन मुझे यकीन है कि विंडोज पर काम करने वाले और अपने दम पर लाइन सेपरेटर्स को सामान्य करने वाले हर व्यक्ति जल्द या बाद में विभिन्न विभाजकों से मैश के साथ एक स्थिति में नहीं आते हैं, इससे पूरी तरह से अनजान हैं।

पायथन 3 लेना

पायथन 3 बहुत बदल गया है, यह एक तथ्य है। एक शक के बिना, हम जिस भविष्य की ओर बढ़ रहे हैं, वह इसके पीछे है। पायथन 3 में बहुत वादा है: एक काफी बेहतर आयात प्रणाली, __qualname__ की उपस्थिति, पायथन पैकेजों को वितरित करने का एक नया तरीका, स्मृति में तार का एक एकीकृत प्रतिनिधित्व।

लेकिन अब, पायथन 3 के लिए एक लाइब्रेरी को पोर्ट करना ऐसा लगता है जैसे कि पायथन 2 में एक लाइब्रेरी विकसित करना और इसे (मेरे फ्रैंच के लिए खेद है) पायथन 3 के लिए स्मार्ट गधे संस्करण के साथ सिर्फ यह साबित करने के लिए कि यह काम करता है। अजगर 3 में जिंजा 2 के बारे में, आप हर तरह से कह सकते हैं कि यह बहुत बदसूरत है। यह भयानक है और मुझे इसके लिए शर्मिंदा होना चाहिए। उदाहरण के लिए, पायथन 3 के संस्करण में, जिन्जा 2 ने दो एक-मेगाबाइट नियमित अभिव्यक्ति को मेमोरी में लोड किया, और मैंने इसे मुक्त करने के बारे में बिल्कुल परवाह नहीं की। मैं चाहता था कि वह किसी तरह काम करे।

तो मुझे जिंजा 2 में मेगाबाइट नियमित अभिव्यक्ति का उपयोग क्यों करना पड़ा? हां, क्योंकि पायथन में रेगेक्स इंजन यूनिकोड श्रेणियों का समर्थन नहीं करता है। और इस तरह के प्रतिबंधों के साथ, मुझे दोनों की कम बुराई को चुनना पड़ा: या तो पायथन 3 में नए यूनिकोड पहचानकर्ताओं पर हथौड़ा चलाना और खुद को ASCII पहचानकर्ताओं तक सीमित करना, या इसमें सभी आवश्यक परिभाषाओं को दर्ज करके मैन्युअल रूप से एक विशाल नियमित अभिव्यक्ति बनाना।

उपरोक्त यह समझाने का सबसे अच्छा उदाहरण है कि मैं पायथन 3 के लिए तैयार क्यों नहीं हूं। यह अपने स्वयं के नवाचारों के साथ काम करने के लिए उपकरण प्रदान नहीं करता है। पायथन 3 यूनिकोड-उन्मुख नियमित अभिव्यक्तियों के लिए महत्वपूर्ण है, इसे उन स्थानों के साथ काम करने के लिए एपीआई की आवश्यकता होती है जो यूनिकोड को ध्यान में रखते हैं। उसे अधिक उन्नत पथ मॉड्यूल की आवश्यकता है जो अंतर्निहित फ़ाइल सिस्टम के व्यवहार को उजागर करता है। यह मजबूत होनी चाहिए पाठ फ़ाइलों के लिए एक एकल मानक एन्कोडिंग, रनटाइम वातावरण से स्वतंत्र। यह एन्कोडेड स्ट्रिंग्स के साथ काम करने के लिए अधिक उपकरण प्रदान करना चाहिए। उसे सिर्फ URL की नहीं बल्कि IRI सपोर्ट की जरूरत है। उसे पैदावार से ज्यादा कुछ चाहिए। इसमें ट्रांसकोडिंग के लिए सहायक तंत्र होना चाहिए, जो कि फाइल सिस्टम में URL की मैपिंग के लिए आवश्यक हैं।

उपरोक्त सभी के लिए, आप Python 2.8 की रिलीज़ को जोड़ सकते हैं, जो Python 3 से थोड़ी नज़दीक होगी। मेरे लिए, Python 3 पर स्विच करने का केवल एक ही वास्तविक तरीका है: पुस्तकालयों और कार्यक्रमों को पूरी तरह से यूनिकोड से अवगत होना चाहिए और नए Python 3 पारिस्थितिकी तंत्र में एकीकृत करना चाहिए।

शौकीनों को अपना मार्ग प्रशस्त न करने दें

पायथन 3 द्वारा की गई सबसे बड़ी गलती पायथन 2 के साथ इसकी द्विआधारी असंगति है। यहां मेरा मतलब है कि पायथन 2 और पायथन 3 दुभाषिए एक समान प्रक्रिया स्थान में एक साथ काम नहीं कर सकते हैं। परिणामस्वरूप, आप पिम्पन 2 और पाइथन 3 दोनों की स्क्रिप्टिंग इंटरफेस के साथ जिम्प को एक साथ शुरू नहीं कर सकते हैं। यही बात विम और ब्लेंडर पर भी लागू होती है। हम बस नहीं कर सकते। अलग-अलग प्रक्रियाओं और कलात्मक आईपीसी के साथ हैक्स का एक गुच्छा लिखना मुश्किल नहीं है, लेकिन किसी को भी इसकी आवश्यकता नहीं है।

इस प्रकार, एक प्रोग्रामर जिसे दूसरों से पहले अजगर 3 सीखना है, वह इसे एक छड़ी के नीचे से करेगा। और यह एक तथ्य नहीं है कि यह प्रोग्रामर आमतौर पर पायथन से परिचित है। और इसका कारण, पूरी ईमानदारी से, यह पैसा पाइथन 2 के इर्द-गिर्द घूमता है। यहां तक ​​कि अगर हम अपनी सारी ऊर्जा पाइथन 3 पर रात में बिताते हैं, तो दोपहर में हम अभी भी पाइथन 2 में लौटेंगे। ऐसा ही कुछ समय के लिए भी होगा। हालाँकि, यदि ग्राफिक डिज़ाइनरों का एक समूह ब्लेंडर में पायथन 3 के तहत स्क्रिप्ट लिखना शुरू कर देता है, तो यहाँ आपके पास आवश्यक अनुकूलन है।

मैं वास्तव में kak पनीर देखना नहीं चाहता हूँ ^*मैं पायथन 3 में कुटिल बंदरगाह बंदरगाहों की प्रचुरता से परेशान हूँ। मैं वास्तव में 2.x और 3.x पर काम करने के लिए डिज़ाइन किया गया एक और जिन्जा 2 और विशेष रूप से बदसूरत कोड का गुच्छा नहीं देखना चाहता। वहाँ, sys.exc_info () [1] जैसे हैक, वाक्यात्मक अंतर को दरकिनार करने के लिए, 2.x और 3.x के साथ रनटाइम पर शाब्दिक रूप से शाब्दिक रूप से परिवर्तित करने के लिए हैक, और भी बहुत कुछ। यह सब न केवल रनटाइम पर प्रदर्शन पर, बल्कि पायथन के कोर टेंट पर भी बुरी तरह से प्रतिबिंबित होता है: हैक के बिना सुंदर और सुपाठ्य कोड।

असफलताओं को जानें, जानें और अनुकूल

अब हमारे लिए एक साथ आने और हर चीज पर चर्चा करने का समय है जो लोग अपने कोड को 2.x और 3.x पर काम करते हैं। प्रौद्योगिकी तेज गति से विकसित हो रही है और पायथन को अलग करके देखने के लिए मुझे बहुत खेद है क्योंकि किसी ने क्षितिज पर काले बादलों की अनदेखी की है।

अजगर "के बारे में भूल जाने के लिए बहुत बड़ा नहीं है।" वह बहुत जल्दी अपनी लोकप्रियता खो सकता है। पास्कल और डेल्फी एक संकीर्ण जगह में गिर गए, इस तथ्य के बावजूद कि वे C # और .NET फ्रेमवर्क के जन्म के बाद भी अद्भुत भाषा बने रहे। सबसे ज्यादा, उनका प्रबंधन उनके पतन से प्रभावित था। लोग अभी भी पास्कल में विकसित हो रहे हैं, लेकिन क्या कई लोग हैं जो इस पर नई परियोजनाएं लिखना शुरू करते हैं? Deplhi iPhone और Android पर काम नहीं करता है। यह UNIX बाजार में बहुत अच्छी तरह से एकीकृत नहीं है। और ईमानदार होने के लिए, पायथन पहले से ही कुछ क्षेत्रों में जमीन खो रहा है। पायथन कंप्यूटर गेम के क्षेत्र में काफी लोकप्रिय था, लेकिन यह ट्रेन लंबे समय से चली आ रही है। वेब-समुदाय में, बारिश के बाद नए प्रतियोगी मशरूम की तरह दिखाई देते हैं, और चाहे हम इसे पसंद करें या नहीं, जावास्क्रिप्ट अधिक से अधिक अक्सर स्क्रिप्टिंग प्रोग्रामिंग भाषा के रूप में पायथन की स्थिति लेता है।

डेल्फी समय में अनुकूल नहीं हो सकी और लोगों ने बस अन्य तकनीकों पर स्विच किया। यदि 2to3 पायथन 3 के लिए हमारा संक्रमण मार्ग है, तो py2js जावास्क्रिप्ट के लिए हमारा संक्रमण पथ है।

और यहाँ मैं क्या सुझाव देता हूं: क्या हम उन सभी चीजों की सूची बना सकते हैं जो पायथन 3 में संक्रमण और उनकी समस्याओं को हल करने के लिए समाधानों की एक सूची को जटिल बनाती हैं? क्या हम पायथन 2.8 विकास पर फिर से चर्चा कर सकते हैं अगर यह पोर्टिंग में मदद कर सकता है? क्या हम PyPy को एक मान्य पायथन कार्यान्वयन के रूप में पहचान सकते हैं, जो हमें कोड लिखने के लिए काफी शक्तिशाली है?

आर्मिन रोनाचेर,
7 दिसंबर, 2011।

एक अनुवादक से: इस लेख को पढ़ने के बाद, पहली इच्छा दूसरों के साथ साझा करने की थी, एक तीव्र सनसनी थी कि "दुनिया को पता होना चाहिए"। मेरे सहयोगी इरीना पिरोगोवा और मेरी पत्नी ऐला मेहदीयेवा ने लेख को फिर से लिखने में मदद की, जिसके लिए उन्हें बहुत धन्यवाद!