अजगर कोड की 4 मिलियन लाइनों की जाँच करने का तरीका। भाग 1

आज हम कैसे ड्रॉपबॉक्स अजगर-कोड प्रकारों को नियंत्रित से निपटने के लिए पर सामग्री के अनुवाद के पहले भाग प्रदान करते हैं।



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

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

→ दूसरा भाग पढ़ें

टाइपिंग क्यों आवश्यक है?

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

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

• क्या यह फ़ंक्शन None वापस कर सकता है?
• यह items तर्क क्या होना चाहिए?
• विशेषता प्रकार क्या है id : int इस है, str शायद उपयोगकर्ता के कुछ प्रकार, या?
• क्या यह तर्क एक सूची होनी चाहिए? क्या इसमें एक टपल पास करना संभव है?

यदि आप निम्न कोड स्निपेट को देखते हैं, तो टाइप एनोटेशन से लैस है, और इस तरह के सवालों के जवाब देने की कोशिश करते हैं, तो यह पता चलता है कि यह सबसे सरल कार्य है:

 class Resource:    id: bytes    ...    def read_metadata(self,                      items: Sequence[str]) -> Dict[str, MetadataItem]:        ... 

• read_metadata कोई नहीं लौटाता है, क्योंकि वापसी प्रकार Optional[…] नहीं है Optional[…] ।
• items तर्क तार का एक क्रम है। इसे किसी भी क्रम में पुनरावृत्त नहीं किया जा सकता है।
• id विशेषता बाइट्स की एक स्ट्रिंग है।

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

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

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

इस तरह के सिस्टम के उपयोग के अन्य फायदे हैं, और वे पहले से ही पूरी तरह से nontrivial हैं:

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

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

Mypy Background

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

प्रकार की जाँच के क्षेत्र में मेरा प्रारंभिक कार्य पायथन के उद्देश्य से नहीं था। इसके बजाय, मैंने छोटी "होम-मेड" भाषा का उपयोग किया। यहां एक उदाहरण दिया गया है, जो आपको बताएगा कि दांव पर क्या है (प्रकार एनोटेशन यहां वैकल्पिक हैं):

 def Fib(n as Int) as Int  if n <= 1    return n  else    return Fib(n - 1) + Fib(n - 2)  end end 

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

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

वास्तव में, भाषा अपने सिस्टम प्रकार द्वारा समर्थित है, इस पल में यह अजगर के नाम से जाना संभव है: यह कुछ प्रतिबंध टिप्पणी प्रकार अजगर 3 वाक्य रचना की वजह से एक अजगर संस्करण था।

यह जावा और अजगर का मिश्रण की तरह देखा:

 int fib(int n):    if n <= 1:        return n    else:        return fib(n - 1) + fib(n - 2) 

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

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

 def fib(n: int) -> int:    if n <= 1:        return n    else:        return fib(n - 1) + fib(n - 2) > पूर्णांक: def fib(n: int) -> int:    if n <= 1:        return n    else:        return fib(n - 1) + fib(n - 2) 

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

 products = [] # type: List[str] # Eww 

पाइथन 2 सपोर्ट के लिए टाइप कमेंट्स भी काम आए, जिसमें टाइप एनोटेशन के लिए बिल्ट-इन सपोर्ट की कमी है:

 f fib(n):    # type: (int) -> int    if n <= 1:        return n    else:        return fib(n - 1) + fib(n - 2) 

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

अपने स्नातक स्तर की पढ़ाई का बचाव करने के बाद, गिदो ने मुझे ड्रॉपबॉक्स में शामिल होने के लिए भी मना लिया। यह वह जगह है जहाँ से खस्ता इतिहास में मज़ा हिस्सा शुरू होता है।

जारी रखने के लिए ...

प्रिय पाठकों! यदि आप पायथन का उपयोग करते हैं, तो कृपया हमें इस भाषा में विकसित होने वाली परियोजनाओं के पैमाने के बारे में बताएं।