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

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

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

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

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

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

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

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

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

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

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

• read_metadata वापस नहीं आता None, चूंकि रिटर्न प्रकार नहीं है Optional[…].
• तर्क items पंक्तियों का एक क्रम है. इसे बेतरतीब ढंग से दोहराया नहीं जा सकता.
• गुण id बाइट्स की एक स्ट्रिंग है.

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

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

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

ऐसी प्रणालियों के उपयोग के अन्य फायदे हैं, और वे पहले से ही पूरी तरह से गैर-तुच्छ हैं:

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

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

मायपी की पृष्ठभूमि

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

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

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

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

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

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

यह जावा और पायथन के मिश्रण जैसा दिखता था:

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

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

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

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)

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

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

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

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

स्रोत: www.habr.com