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

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

→ भाग एक पढ़ें

आधिकारिक प्रकार का समर्थन (पीईपी 484)

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

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

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

अंततः जिस प्रकार के संकेत सिंटैक्स को अपनाया गया, वह उस समय Mypy द्वारा समर्थित के समान था। पीईपी 484 को 3.5 में पायथन 2015 के साथ जारी किया गया था। पायथन अब गतिशील रूप से टाइप की जाने वाली भाषा नहीं रही। मैं इस घटना को पायथन इतिहास में एक महत्वपूर्ण मील का पत्थर मानता हूं।

प्रवास की शुरुआत

2015 के अंत में, ड्रॉपबॉक्स ने mypy पर काम करने के लिए तीन लोगों की एक टीम बनाई। उनमें गुइडो वैन रोसुम, ग्रेग प्राइस और डेविड फिशर शामिल थे। उसी क्षण से, स्थिति बहुत तेज़ी से विकसित होने लगी। Mypy के विकास में पहली बाधा प्रदर्शन थी। जैसा कि मैंने ऊपर संकेत दिया था, परियोजना के शुरुआती दिनों में मैंने mypy कार्यान्वयन को C में अनुवाद करने के बारे में सोचा था, लेकिन यह विचार अभी सूची से हटा दिया गया था। हम CPython दुभाषिया का उपयोग करके सिस्टम चलाने में फंस गए थे, जो mypy जैसे टूल के लिए पर्याप्त तेज़ नहीं है। (PyPy प्रोजेक्ट, JIT कंपाइलर के साथ एक वैकल्पिक पायथन कार्यान्वयन, ने भी हमारी मदद नहीं की।)

सौभाग्य से, यहां कुछ एल्गोरिथम सुधार हमारी सहायता के लिए आए हैं। पहला शक्तिशाली "त्वरक" वृद्धिशील जाँच का कार्यान्वयन था। इस सुधार के पीछे का विचार सरल था: यदि सभी मॉड्यूल की निर्भरताएँ mypy के पिछले रन के बाद से नहीं बदली हैं, तो हम निर्भरता के साथ काम करते समय पिछले रन के दौरान कैश किए गए डेटा का उपयोग कर सकते हैं। हमें केवल संशोधित फ़ाइलों और उन पर निर्भर फ़ाइलों पर प्रकार की जाँच करने की आवश्यकता थी। Mypy और भी आगे बढ़ गया: यदि मॉड्यूल का बाहरी इंटरफ़ेस नहीं बदला, तो mypy ने मान लिया कि इस मॉड्यूल को आयात करने वाले अन्य मॉड्यूल को दोबारा जांचने की आवश्यकता नहीं है।

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

यह ड्रॉपबॉक्स पर टाइप चेकिंग को तेजी से और स्वाभाविक रूप से अपनाने का दौर था। 2016 के अंत तक, हमारे पास पहले से ही टाइप एनोटेशन के साथ पायथन कोड की लगभग 420000 लाइनें थीं। कई उपयोगकर्ता टाइप चेकिंग को लेकर उत्साहित थे। अधिक से अधिक विकास दल ड्रॉपबॉक्स मायपी का उपयोग कर रहे थे।

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

अधिक उत्पादकता!

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

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

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

और भी अधिक उत्पादकता!

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

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

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

कंपाइलर, जिसे हम mypyc कहते हैं (क्योंकि यह प्रकारों का विश्लेषण करने के लिए फ्रंट-एंड के रूप में mypy का उपयोग करता है), एक बहुत ही सफल प्रोजेक्ट साबित हुआ। कुल मिलाकर, हमने कैशिंग के बिना लगातार मायपी रन के लिए लगभग 4x स्पीडअप हासिल किया। Mypyc प्रोजेक्ट के मूल को विकसित करने में माइकल सुलिवन, इवान लेवकिव्स्की, ह्यूग हैन और मेरी एक छोटी सी टीम को लगभग 4 कैलेंडर महीने लगे। काम की यह मात्रा mypy को फिर से लिखने के लिए आवश्यक मात्रा से बहुत कम थी, उदाहरण के लिए, C++ या Go में। और हमें प्रोजेक्ट में बहुत कम बदलाव करने पड़े, जितना हमें इसे किसी अन्य भाषा में दोबारा लिखते समय करना पड़ता। हमें यह भी उम्मीद थी कि हम mypyc को ऐसे स्तर पर ला सकते हैं कि अन्य ड्रॉपबॉक्स प्रोग्रामर इसका उपयोग अपने कोड को संकलित करने और तेज़ करने के लिए कर सकें।

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

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

को जारी रखा जाएगा ...

प्रिय पाठकों! जब आपको mypy प्रोजेक्ट के अस्तित्व के बारे में पता चला तो उसके बारे में आपकी क्या राय थी?

स्रोत: www.habr.com