पायथन कोड की 4 मिलियन पंक्तियों को टाइप करने का पथ। भाग ---- पहला

हम आपके ध्यान में उस पथ के बारे में सामग्री के अनुवाद का तीसरा भाग प्रस्तुत करते हैं जो ड्रॉपबॉक्स ने पायथन कोड के लिए एक प्रकार की जाँच प्रणाली को लागू करते समय अपनाया था।

→ पिछले भाग: पहले и दूसरा

टाइप किए गए कोड की 4 मिलियन पंक्तियों तक पहुँचना

एक और बड़ी चुनौती (और आंतरिक रूप से सर्वेक्षण किए गए लोगों के बीच दूसरी सबसे आम चिंता) ड्रॉपबॉक्स में टाइप चेक द्वारा कवर किए गए कोड की मात्रा में वृद्धि करना था। हमने इस समस्या को हल करने के लिए कई तरीकों की कोशिश की है, टाइप किए गए कोडबेस के आकार को स्वाभाविक रूप से बढ़ाने से लेकर स्थिर और गतिशील स्वचालित प्रकार के अनुमान पर mypy टीम के प्रयासों पर ध्यान केंद्रित करने तक। अंत में, ऐसा लगा कि जीतने की कोई आसान रणनीति नहीं थी, लेकिन हम कई दृष्टिकोणों को मिलाकर एनोटेट कोड की मात्रा में तेजी से वृद्धि हासिल करने में सक्षम थे।

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

हमने टाइप सिस्टम की नई सुविधाओं को लागू किया (और बाद के पीईपी में मानकीकृत किया) जो कुछ विशिष्ट पायथन पैटर्न के लिए अधिक सटीक प्रकारों की अनुमति देते हैं। इसका एक उल्लेखनीय उदाहरण है TypeDict, जो JSON-जैसे शब्दकोशों के लिए प्रकार प्रदान करता है जिनमें स्ट्रिंग कुंजियों का एक निश्चित सेट होता है, प्रत्येक का अपना प्रकार का मान होता है। हम टाइप सिस्टम का विस्तार करना जारी रखेंगे। हमारा अगला कदम संभवतः पायथन की संख्यात्मक क्षमताओं के लिए समर्थन में सुधार करना होगा।

एनोटेटेड कोड की पंक्तियों की संख्या: सर्वर

एनोटेटेड कोड की पंक्तियों की संख्या: क्लाइंट

एनोटेट कोड की पंक्तियों की कुल संख्या

ड्रॉपबॉक्स में एनोटेटेड कोड की मात्रा बढ़ाने के लिए हमने जो कुछ किया उसकी मुख्य विशेषताओं का अवलोकन यहां दिया गया है:

एनोटेशन कठोरता. हमने नए कोड को एनोटेट करने की कठोरता के लिए आवश्यकताओं को धीरे-धीरे बढ़ाया। हमने लिंटर युक्तियों से शुरुआत की जो उन फ़ाइलों में एनोटेशन जोड़ने का सुझाव देती थी जिनमें पहले से ही कुछ एनोटेशन थे। अब हमें नई पायथन फ़ाइलों और अधिकांश मौजूदा फ़ाइलों में टाइप एनोटेशन की आवश्यकता है।

रिपोर्ट टाइप करना. हम टीमों को उनके कोड में टाइपिंग के स्तर पर साप्ताहिक रिपोर्ट भेजते हैं और सलाह देते हैं कि पहले क्या एनोटेट किया जाना चाहिए।

मायपी को लोकप्रिय बनाना। हम आयोजनों में mypy के बारे में बात करते हैं और टाइप एनोटेशन के साथ शुरुआत करने में मदद करने के लिए टीमों से बात करते हैं।

मतदान. हम प्रमुख समस्याओं की पहचान करने के लिए समय-समय पर उपयोगकर्ता सर्वेक्षण आयोजित करते हैं। हम इन समस्याओं को हल करने के लिए बहुत आगे तक जाने के लिए तैयार हैं (यहाँ तक कि mypy को तेज़ करने के लिए एक नई भाषा भी बना रहे हैं!)।

प्रदर्शन। हमने डेमॉन और मायपाइक का उपयोग करके मायपी के प्रदर्शन में काफी सुधार किया है। एनोटेशन प्रक्रिया के दौरान उत्पन्न होने वाली असुविधाओं को दूर करने और बड़ी मात्रा में कोड के साथ काम करने में सक्षम होने के लिए ऐसा किया गया था।

संपादकों के साथ एकीकरण. हमने संपादकों में mypy चलाने का समर्थन करने के लिए उपकरण बनाए हैं जो ड्रॉपबॉक्स पर लोकप्रिय हैं। इसमें PyCharm, Vim और VS Code शामिल हैं। इससे कोड को एनोटेट करने और उसकी कार्यक्षमता की जांच करने की प्रक्रिया बहुत सरल हो गई। मौजूदा कोड को एनोटेट करते समय इस प्रकार की कार्रवाइयां आम हैं।

स्थैतिक विश्लेषण. हमने स्थैतिक विश्लेषण टूल का उपयोग करके फ़ंक्शन हस्ताक्षरों का अनुमान लगाने के लिए एक टूल बनाया। यह उपकरण केवल अपेक्षाकृत सरल स्थितियों में ही काम कर सकता है, लेकिन इससे हमें बिना अधिक प्रयास के अपने कोड प्रकार के कवरेज को बढ़ाने में मदद मिली।

तृतीय पक्ष पुस्तकालयों के लिए समर्थन. हमारे कई प्रोजेक्ट SQLAlchemy टूलकिट का उपयोग करते हैं। यह पायथन की गतिशील क्षमताओं का लाभ उठाता है कि पीईपी 484 प्रकार सीधे मॉडल करने में असमर्थ हैं। हमने, पीईपी 561 के अनुसार, संबंधित स्टब फ़ाइल बनाई और mypy के लिए एक प्लगइन लिखा (खुला स्त्रोत), जो SQLAlchemy समर्थन को बेहतर बनाता है।

हमें जिन कठिनाइयों का सामना करना पड़ा

टाइप किए गए कोड की 4 मिलियन पंक्तियों तक का रास्ता हमारे लिए हमेशा आसान नहीं रहा है। इस रास्ते पर हमें कई गड्ढों का सामना करना पड़ा और कई गलतियाँ हुईं। ये कुछ समस्याएं हैं जिनका हमने सामना किया। हमें उम्मीद है कि इनके बारे में बताने से दूसरों को भी ऐसी ही समस्याओं से बचने में मदद मिलेगी।

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

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

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

चक्रीय आयात. ऊपर, मैंने चक्रीय आयात ("निर्भरता उलझन") के बारे में बात की, जिसके अस्तित्व ने मायपी को गति देना मुश्किल बना दिया। हमें mypy को इन चक्रीय आयातों के कारण होने वाले सभी प्रकार के मुहावरों का समर्थन करने के लिए भी कड़ी मेहनत करनी पड़ी। हमने हाल ही में एक प्रमुख सिस्टम रीडिज़ाइन प्रोजेक्ट पूरा किया है, जिसने सर्कुलर आयात के संबंध में mypy की अधिकांश समस्याओं को ठीक कर दिया है। ये समस्याएँ वास्तव में परियोजना के शुरुआती दिनों से ही उत्पन्न हुई थीं, अलोरे से, वह शैक्षिक भाषा जिस पर मायपी परियोजना मूल रूप से केंद्रित थी। अलोर सिंटैक्स चक्रीय आयात कमांड के साथ समस्याओं को हल करना आसान बनाता है। आधुनिक मायपी को इसके पहले, सरल-दिमाग वाले कार्यान्वयन (जो अलोरे के लिए बहुत उपयुक्त था) से कुछ सीमाएँ विरासत में मिली हैं। पायथन सर्कुलर आयात के साथ काम करना कठिन बना देता है, मुख्यतः क्योंकि अभिव्यक्तियाँ अस्पष्ट होती हैं। उदाहरण के लिए, एक असाइनमेंट ऑपरेशन वास्तव में एक प्रकार का उपनाम परिभाषित कर सकता है। Mypy हमेशा इस तरह की चीजों का पता लगाने में सक्षम नहीं होता है जब तक कि अधिकांश आयात लूप संसाधित नहीं हो जाता। अलोर में ऐसी कोई अस्पष्टता नहीं थी। सिस्टम विकास के शुरुआती चरणों में लिए गए खराब निर्णय कई वर्षों बाद प्रोग्रामर के लिए एक अप्रिय आश्चर्य प्रस्तुत कर सकते हैं।

परिणाम: कोड की 5 मिलियन लाइनों और नए क्षितिज का मार्ग

Mypy प्रोजेक्ट ने एक लंबा सफर तय किया है - शुरुआती प्रोटोटाइप से लेकर एक सिस्टम तक जो उत्पादन कोड प्रकारों की 4 मिलियन लाइनों को नियंत्रित करता है। जैसे-जैसे मायपी विकसित हुई, पायथन के प्रकार के संकेतों को मानकीकृत किया गया। इन दिनों, पायथन कोड टाइप करने के इर्द-गिर्द एक शक्तिशाली पारिस्थितिकी तंत्र विकसित हो गया है। इसमें पुस्तकालय समर्थन के लिए एक जगह है, इसमें आईडीई और संपादकों के लिए सहायक उपकरण शामिल हैं, इसमें कई प्रकार की नियंत्रण प्रणालियाँ हैं, जिनमें से प्रत्येक के अपने फायदे और नुकसान हैं।

हालाँकि ड्रॉपबॉक्स पर टाइप चेकिंग पहले से ही दी गई है, मेरा मानना ​​है कि हम अभी भी पायथन कोड टाइप करने के शुरुआती दिनों में हैं। मुझे लगता है कि टाइप चेकिंग तकनीकें विकसित और बेहतर होती रहेंगी।

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

प्रिय पाठकों! क्या आप अपने पायथन प्रोजेक्ट्स में टाइप चेकिंग का उपयोग करते हैं?

स्रोत: www.habr.com