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

आज हामी Dropbox Python कोड प्रकार नियन्त्रणसँग कसरी व्यवहार गर्छ भन्ने बारे सामग्रीको अनुवादको पहिलो भाग तपाईंको ध्यानाकर्षण गराउँछौं।

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

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

→ दोस्रो भाग पढ्नुहोस्

टाइप जाँच किन आवश्यक छ?

यदि तपाईंले कहिल्यै गतिशील रूपमा टाइप गरिएको पाइथन प्रयोग गर्नुभएको छ भने, तपाईं हालै स्थिर टाइपिङ र 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 बाइटको स्ट्रिङ हो।

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

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

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

त्यस्ता प्रणालीहरूको प्रयोगमा अन्य फाइदाहरू छन्, र तिनीहरू पूर्ण रूपमा गैर-तुच्छ छन्:

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

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

Mypy पृष्ठभूमि

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

टाइप जाँचमा मेरो प्रारम्भिक काम पाइथनमा लक्षित थिएन। बरु मैले सानो "घरेलु" भाषा प्रयोग गरें अलोर। हामी के कुरा गर्दैछौं भन्ने बारे तपाईंलाई एक विचार दिनको लागि यहाँ एउटा उदाहरण छ (प्रकार एनोटेसनहरू ऐच्छिक छन्):

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

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

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

वास्तवमा, मेरो प्रकार प्रणाली द्वारा समर्थित भाषालाई यस बिन्दुमा पाइथन भन्न सकिँदैन: यो पाइथन 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)

मैले केही सम्झौताहरू गर्नुपर्‍यो (सबैभन्दा पहिले, म यो कुरा औंल्याउन चाहन्छु कि यही कारणले मैले आफ्नै वाक्य रचनाको आविष्कार गरें)। विशेष गरी, पाइथन ३.३, त्यस समयमा भाषाको सबैभन्दा भर्खरको संस्करणले चर एनोटेसनहरूलाई समर्थन गर्दैन। मैले इमेल मार्फत Guido सँग त्यस्ता एनोटेसनहरूको लागि विभिन्न सिन्ट्याक्टिक विकल्पहरू छलफल गरें। हामीले चरका लागि प्रकार टिप्पणीहरू प्रयोग गर्ने निर्णय गर्यौं। यसले लक्ष्य हासिल गर्‍यो, तर थोरै बोझिलो देखिन्थ्यो (पाइथन ३.६ ले हामीलाई राम्रो वाक्य रचना दियो):

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

पाइथन २ लाई समर्थन गर्नका लागि टाइप टिप्पणीहरू पनि उपयोगी छन्, जसमा टाइप एनोटेसनहरूको लागि निर्मित समर्थन छैन:

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

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

मैले मेरो सिनियर थेसिस पूरा गरेपछि गुइडोले मलाई ड्रपबक्समा सामेल हुन पनि मनाउनुभयो। Mypy को इतिहासको सबैभन्दा रोचक कुरा यहीँबाट सुरु हुन्छ।

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

प्रिय पाठकहरु! यदि तपाइँ पाइथन प्रयोग गर्नुहुन्छ भने, कृपया हामीलाई तपाइँले यस भाषामा विकास गर्ने परियोजनाहरूको मापनको बारेमा बताउनुहोस्।

स्रोत: www.habr.com