पाइथन कोडको ४ मिलियन लाइनहरू टाइप चेक गर्ने बाटो। भाग 4

आज हामी Dropbox ले Python कोड को लाखौं लाइनहरु को लागी प्रकार नियन्त्रण संगठित कसरी बारे मा सामग्री को अनुवाद को दोस्रो भाग प्रकाशित गर्दैछौं।

→ भाग एक पढ्नुहोस्

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

हामीले ह्याक हप्ता 2014 मा ड्रपबक्समा mypy सँग हाम्रो पहिलो गम्भीर प्रयोगहरू सञ्चालन गर्यौं। ह्याक हप्ता ड्रपबक्स द्वारा आयोजित एक हप्ताको कार्यक्रम हो। यस समयमा, कर्मचारीहरूले आफूले चाहेको काम गर्न सक्छन्! Dropbox का केहि प्रख्यात टेक्नोलोजी परियोजनाहरू यस्ता घटनाहरूमा सुरु भयो। यस प्रयोगको नतिजाको रूपमा, हामीले निष्कर्ष निकाल्यौं कि mypy आशाजनक देखिन्छ, यद्यपि परियोजना अझै व्यापक प्रयोगको लागि तयार छैन।

त्यस समयमा, पाइथन प्रकारको संकेत प्रणालीलाई मानकीकरण गर्ने विचार हावामा थियो। मैले भनेझैं, Python 3.0 बाट प्रकार्यहरूको लागि टाइप एनोटेसनहरू प्रयोग गर्न सम्भव थियो, तर यी केवल स्वेच्छाचारी अभिव्यक्तिहरू थिए, परिभाषित सिन्ट्याक्स र सिमान्टिक्स बिना। कार्यक्रम कार्यान्वयनको क्रममा, यी एनोटेसनहरू, अधिकांश भागको लागि, केवल बेवास्ता गरियो। Hack Week पछि, हामीले सिमान्टिक्सलाई मानकीकरणमा काम गर्न थाल्यौं। यो कामको उदय भयो पीईपी ३४३ (Guido van Rossum, Łukasz Langa र मैले यो कागजातमा सहकार्य गरेका थियौं)।

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

प्रकार सङ्केत वाक्यविन्यास जुन अन्ततः अपनाईएको थियो mypy ले समर्थन गरेको कुरासँग मिल्दोजुल्दो थियो। PEP 484 3.5 मा Python 2015 को साथ जारी गरिएको थियो। पाइथन अब गतिशील रूपमा टाइप गरिएको भाषा थिएन। म यस घटनालाई पाइथन इतिहासमा महत्त्वपूर्ण कोसेढुङ्गाको रूपमा सोच्न चाहन्छु।

माइग्रेसनको सुरुवात

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

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

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

यो ड्रपबक्समा प्रकार जाँचको द्रुत र प्राकृतिक अपनाउने अवधि थियो। 2016 को अन्त्यमा, हामीसँग पहिले नै टाइप एनोटेसनहरूसँग पाइथन कोडको लगभग 420000 लाइनहरू थिए। धेरै प्रयोगकर्ताहरू प्रकार जाँचको बारेमा उत्साहित थिए। अधिक र अधिक विकास टोलीहरू Dropbox mypy प्रयोग गर्दै थिए।

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

थप उत्पादकता!

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

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

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

अझ बढी उत्पादकता!

मैले माथि छलफल गरेको रिमोट क्यासिङको साथमा, माइपी डेमनले लगभग पूर्ण रूपमा समस्याहरू समाधान गर्यो जुन एक प्रोग्रामरले प्रायः टाइप जाँच चलाउँछ, फाइलहरूको सानो संख्यामा परिवर्तनहरू गर्दै। यद्यपि, कम्तिमा अनुकूल प्रयोगको अवस्थामा प्रणाली प्रदर्शन अझै पनि इष्टतमबाट टाढा थियो। Mypy को सफा स्टार्टअपले 15 मिनेट भन्दा बढी लिन सक्छ। र यो हामी खुसी हुने भन्दा धेरै थियो। प्रोग्रामरहरूले नयाँ कोड लेख्न र अवस्थित कोडमा एनोटेशनहरू थप्न जारी राख्दा प्रत्येक हप्ता स्थिति खराब भयो। हाम्रा प्रयोगकर्ताहरू अझै धेरै प्रदर्शनको लागि भोका थिए, तर हामी उनीहरूलाई आधा बाटोमा भेट्न पाउँदा खुसी थियौं।

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

CPython एक्स्टेन्सन API मा फोकस गर्नु परियोजना व्यवस्थापन क्षमताहरू गुमाउनु हुँदैन। हामीले भर्चुअल मेसिन वा mypy लाई आवश्यक पर्ने कुनै पनि पुस्तकालयहरू लागू गर्न आवश्यक पर्दैन। थप रूपमा, हामीसँग अझै पनि सम्पूर्ण पाइथन इकोसिस्टम र सबै उपकरणहरूमा पहुँच हुनेछ (जस्तै pytest)। यसको मतलब हामीले विकासको समयमा व्याख्या गरिएको पाइथन कोड प्रयोग गर्न जारी राख्न सक्छौं, हामीलाई कोड परिवर्तन गर्न र परीक्षण गर्ने धेरै छिटो ढाँचाको साथ काम जारी राख्न अनुमति दिँदै, कोड कम्पाइलको लागि पर्खनुको सट्टा। यस्तो देखिन्थ्यो कि हामीले दुई कुर्सीहरूमा बसेर राम्रो काम गरिरहेका थियौं, त्यसैले बोल्न, र हामीलाई यो मन पर्यो।

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

प्रदर्शनको यो स्तर हासिल गर्न, हामीले केही रोचक इन्जिनियरिङ समाधानहरू लागू गर्नुपर्‍यो। यसरी, कम्पाइलरले छिटो, कम-स्तर C निर्माणहरू प्रयोग गरेर धेरै कार्यहरूलाई गति दिन सक्छ। उदाहरणका लागि, कम्पाइल गरिएको प्रकार्य कललाई C प्रकार्य कलमा अनुवाद गरिन्छ। र यस्तो कल एक व्याख्या प्रकार्य कल भन्दा धेरै छिटो छ। केही अपरेसनहरू, जस्तै शब्दकोश लुकअपहरू, अझै पनि CPython बाट नियमित C-API कलहरू प्रयोग गरेर संलग्न छन्, जुन कम्पाइल गर्दा थोरै मात्र छिटो थियो। हामी व्याख्या द्वारा बनाईएको प्रणालीमा अतिरिक्त भार हटाउन सक्षम थियौं, तर यस अवस्थामा यसले प्रदर्शनको सन्दर्भमा मात्र सानो लाभ दियो।

सबैभन्दा सामान्य "ढिलो" कार्यहरू पहिचान गर्न, हामीले कोड प्रोफाइलिङ प्रदर्शन गर्यौं। यस डेटासँग सशस्त्र, हामीले या त mypyc लाई ट्वीक गर्ने प्रयास गर्यौं ताकि यसले त्यस्ता अपरेसनहरूको लागि छिटो C कोड उत्पन्न गर्छ, वा छिटो अपरेशनहरू प्रयोग गरेर सम्बन्धित पाइथन कोड पुन: लेख्न सक्छ (र कहिलेकाहीँ हामीसँग त्यो वा अन्य समस्याको लागि पर्याप्त सरल समाधान थिएन)। । पाइथन कोड पुन: लेख्नु प्रायः कम्पाइलरले स्वचालित रूपमा समान रूपान्तरण प्रदर्शन गर्नु भन्दा समस्याको सजिलो समाधान थियो। लामो अवधिमा, हामी यी धेरै परिवर्तनहरू स्वचालित गर्न चाहन्थ्यौं, तर त्यस समयमा हामी न्यूनतम प्रयासको साथ mypy को गतिमा केन्द्रित थियौं। र यो लक्ष्य तिर बढ्दै, हामीले धेरै कुनाहरू काट्यौं।

फेरि जारी राखौंला…

प्रिय पाठकहरु! Mypy परियोजनाको अस्तित्वको बारेमा थाहा पाउँदा तपाईंको प्रभाव के थियो?

स्रोत: www.habr.com