पायथन कोडच्या ४ दशलक्ष ओळी तपासण्याचा मार्ग. भाग 4

आज आम्ही ड्रॉपबॉक्स पायथन कोडच्या प्रकार नियंत्रणाशी कसे व्यवहार करतो यावरील सामग्रीच्या भाषांतराचा पहिला भाग तुमच्या लक्षात आणून देतो.

ड्रॉपबॉक्स पायथनमध्ये बरेच काही लिहितो. ही एक भाषा आहे जी आम्ही बॅक-एंड सेवा आणि डेस्कटॉप क्लायंट ऍप्लिकेशन्ससाठी मोठ्या प्रमाणावर वापरतो. आम्ही Go, TypeScript आणि Rust देखील खूप वापरतो, पण Python ही आमची मुख्य भाषा आहे. आमच्या स्केलचा विचार करून, आणि आम्ही पायथन कोडच्या लाखो ओळींबद्दल बोलत आहोत, असे दिसून आले की अशा कोडच्या डायनॅमिक टायपिंगमुळे त्याची समज अनावश्यकपणे गुंतागुंतीची झाली आणि कामगार उत्पादकतेवर गंभीरपणे परिणाम होऊ लागला. ही समस्या कमी करण्यासाठी, आम्ही हळूहळू आमचा कोड mypy वापरून स्टॅटिक टाइप चेकिंगमध्ये बदलण्यास सुरुवात केली आहे. पायथनसाठी ही कदाचित सर्वात लोकप्रिय स्टँडअलोन प्रकार तपासणी प्रणाली आहे. Mypy हा एक मुक्त स्रोत प्रकल्प आहे, त्याचे मुख्य विकासक ड्रॉपबॉक्समध्ये काम करतात.

या प्रमाणात पायथन कोडमध्ये स्टॅटिक टाइप चेकिंग लागू करणाऱ्या पहिल्या कंपन्यांपैकी ड्रॉपबॉक्स ही एक होती. आजकाल हजारो प्रकल्पांमध्ये Mypy वापरला जातो. हे साधन असंख्य वेळा, जसे ते म्हणतात, "लढाईत चाचणी केली." आपण आता जिथे आहोत तिथे पोहोचण्यासाठी आपण खूप पुढे आलो आहोत. वाटेत, अनेक अयशस्वी उपक्रम आणि अयशस्वी प्रयोग होते. या पोस्टमध्ये पायथनमधील स्थिर प्रकार तपासणीचा इतिहास समाविष्ट आहे, माझ्या संशोधन प्रकल्पाचा एक भाग म्हणून त्याच्या खडतर सुरुवातीपासून ते आजपर्यंत, जेव्हा पायथनमध्ये लिहिणाऱ्या असंख्य विकसकांसाठी टाइप चेकिंग आणि टाइप हिंटिंग सामान्य झाले आहे. या यंत्रणांना आता IDEs आणि कोड विश्लेषक यांसारख्या अनेक साधनांद्वारे समर्थित केले जाते.

→ दुसरा भाग वाचा

टाइप तपासणे का आवश्यक आहे?

जर तुम्ही डायनॅमिकली टाइप केलेला पायथन वापरला असेल, तर अलीकडे स्टॅटिक टायपिंग आणि मायपी बद्दल एवढा गडबड का झाली आहे याबद्दल तुम्हाला काही गोंधळ होऊ शकतो. किंवा कदाचित तुम्हाला पायथन त्याच्या डायनॅमिक टायपिंगमुळे तंतोतंत आवडत असेल आणि जे घडत आहे ते तुम्हाला अस्वस्थ करते. स्टॅटिक टायपिंगच्या मूल्याची गुरुकिल्ली म्हणजे सोल्यूशन्सचे स्केल: तुमचा प्रोजेक्ट जितका मोठा असेल तितका तुम्ही स्टॅटिक टायपिंगकडे झुकता आणि शेवटी, तुम्हाला तितकी जास्त गरज असते.

समजा एखादा विशिष्ट प्रकल्प हजारो ओळींच्या आकारात पोहोचला आहे आणि असे दिसून आले की अनेक प्रोग्रामर त्यावर काम करत आहेत. आमच्या अनुभवाच्या आधारे तत्सम प्रकल्प पाहता, आम्ही असे म्हणू शकतो की त्याचा कोड समजून घेणे ही विकासकांना उत्पादक ठेवण्याची गुरुकिल्ली असेल. टाईप एनोटेशन्सशिवाय, हे समजणे कठीण होऊ शकते, उदाहरणार्थ, फंक्शनला कोणते वितर्क पास करायचे किंवा फंक्शन कोणत्या प्रकारचे परत येऊ शकते. येथे सामान्य प्रश्न आहेत ज्यांची उत्तरे टाइप भाष्ये न वापरता देणे कठीण असते:

• हे कार्य परत येऊ शकते None?
• हा युक्तिवाद काय असावा? items?
• विशेषता प्रकार काय आहे id: int खरचं, str, किंवा कदाचित काही सानुकूल प्रकार?
• या युक्तिवादाची यादी असावी का? ते एक tuple पास करणे शक्य आहे का?

तुम्ही खालील टाइप-एनोटेटेड कोड स्निपेट पाहिल्यास आणि तत्सम प्रश्नांची उत्तरे देण्याचा प्रयत्न केल्यास, असे दिसून येते की हे सर्वात सोपे कार्य आहे:

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

• read_metadata परत येत नाही None, कारण रिटर्न प्रकार नाही Optional[…].
• युक्तिवाद items ओळींचा क्रम आहे. ते यादृच्छिकपणे पुनरावृत्ती करता येत नाही.
• गुणधर्म id बाइट्सची स्ट्रिंग आहे.

आदर्श जगात, अशा सर्व सूक्ष्मतेचे वर्णन अंगभूत दस्तऐवजीकरण (डॉक्स्ट्रिंग) मध्ये केले जाईल अशी अपेक्षा आहे. परंतु अनुभव या वस्तुस्थितीची बरीच उदाहरणे देतो की आपल्याला ज्या कोडसह कार्य करावे लागेल त्यामध्ये असे दस्तऐवजीकरण सहसा पाहिले जात नाही. जरी असे दस्तऐवजीकरण कोडमध्ये असले तरीही, त्याच्या अचूकतेवर विश्वास ठेवता येत नाही. हे दस्तऐवजीकरण अस्पष्ट, चुकीचे आणि गैरसमजांसाठी खुले असू शकते. मोठ्या संघात किंवा मोठ्या प्रकल्पांमध्ये, ही समस्या अत्यंत तीव्र होऊ शकते.

पायथन प्रकल्पांच्या सुरुवातीच्या किंवा मध्यवर्ती टप्प्यात उत्कृष्ट असताना, काही ठिकाणी यशस्वी प्रकल्प आणि पायथन वापरणाऱ्या कंपन्यांना महत्त्वाच्या प्रश्नाचा सामना करावा लागू शकतो: “आम्ही सर्व काही स्थिरपणे टाइप केलेल्या भाषेत पुन्हा लिहावे का?”.

mypy सारख्या टाइप चेकिंग सिस्टम विकासकाला प्रकारांचे वर्णन करण्यासाठी औपचारिक भाषा देऊन वरील समस्या सोडवतात आणि प्रकार घोषणा कार्यक्रम अंमलबजावणीशी जुळतात हे तपासून (आणि पर्यायाने त्यांचे अस्तित्व तपासून). सर्वसाधारणपणे, आम्ही असे म्हणू शकतो की या प्रणाली काळजीपूर्वक तपासलेल्या कागदपत्रांसारखे काहीतरी आमच्या विल्हेवाट लावतात.

अशा प्रणालींच्या वापराचे इतर फायदे आहेत आणि ते आधीच पूर्णपणे गैर-क्षुल्लक आहेत:

• प्रकार तपासणी प्रणाली काही लहान (आणि इतक्या लहान नसलेल्या) त्रुटी शोधू शकते. एक नमुनेदार उदाहरण म्हणजे जेव्हा ते एखाद्या मूल्यावर प्रक्रिया करण्यास विसरतात None किंवा इतर काही विशेष स्थिती.
• कोड रीफॅक्टरिंग मोठ्या प्रमाणात सरलीकृत केले आहे कारण टाइप चेकिंग सिस्टम अनेकदा कोणता कोड बदलण्याची आवश्यकता आहे याबद्दल अगदी अचूक असते. त्याच वेळी, आम्हाला चाचण्यांसह 100% कोड कव्हरेजची आशा करण्याची गरज नाही, जे कोणत्याही परिस्थितीत सहसा व्यवहार्य नसते. समस्येचे कारण शोधण्यासाठी आम्हाला स्टॅक ट्रेसच्या खोलात जाण्याची गरज नाही.
• मोठ्या प्रकल्पांवरही, mypy अनेकदा एका सेकंदाच्या अंशामध्ये पूर्ण प्रकार तपासू शकते. आणि चाचण्या अंमलात आणण्यासाठी सहसा दहा सेकंद किंवा मिनिटे लागतात. प्रकार तपासणी प्रणाली प्रोग्रामरला त्वरित अभिप्राय देते आणि त्याला त्याचे काम जलद करण्यास अनुमती देते. त्याला यापुढे फक्त कोड चाचणी परिणाम जलद मिळण्यासाठी वास्तविक घटकांच्या जागी मॉक आणि पॅच असलेल्या युनिट चाचण्या राखण्यासाठी नाजूक आणि कठीण लिहिण्याची आवश्यकता नाही.

IDEs आणि संपादक जसे की PyCharm किंवा Visual Studio Code विकासकांना कोड पूर्ण करणे, त्रुटी हायलाइट करणे आणि सामान्यतः वापरल्या जाणार्‍या भाषा रचनांसाठी समर्थन प्रदान करण्यासाठी टाईप एनोटेशनची शक्ती वापरतात. आणि हे फक्त टायपिंगचे काही फायदे आहेत. काही प्रोग्रामरसाठी, हे सर्व टायपिंगच्या बाजूने मुख्य युक्तिवाद आहे. ही अशी गोष्ट आहे जी अंमलबजावणी केल्यानंतर लगेचच फायदा होतो. प्रकारांसाठी या वापर प्रकरणासाठी 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 bytecode संकलित करून कार्यप्रदर्शन सुधारण्यासाठी टाइप भाष्ये वापरणे. मी कंपाइलर प्रोटोटाइप लिहिण्याच्या टप्प्यावर पोहोचलो, परंतु मी ही कल्पना सोडून दिली, कारण टाइप चेकिंग स्वतःच खूप उपयुक्त वाटले.

मी सांता क्लारा मधील PyCon 2013 मध्ये माझा प्रकल्प सादर केला. मी याविषयी आयुष्यभर परोपकारी पायथन हुकूमशहा गुइडो व्हॅन रोसम यांच्याशीही बोललो. त्याने मला माझे स्वतःचे वाक्यरचना सोडण्यास आणि मानक पायथन 3 वाक्यरचनासह चिकटून राहण्यास पटवून दिले. पायथन 3 फंक्शन भाष्यांना समर्थन देते, त्यामुळे माझे उदाहरण खाली दर्शविल्याप्रमाणे पुन्हा लिहिले जाऊ शकते, परिणामी पायथन प्रोग्राम सामान्य होईल:

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

मला काही तडजोड करावी लागली (सर्वप्रथम, मला हे लक्षात घ्यायचे आहे की मी माझ्या स्वतःच्या वाक्यरचनेचा शोध याच कारणासाठी लावला आहे). विशेषतः, Python 3.3, त्यावेळच्या भाषेची सर्वात अलीकडील आवृत्ती, परिवर्तनीय भाष्यांना समर्थन देत नाही. अशा भाष्यांच्या सिंटॅक्टिक डिझाइनसाठी मी ई-मेलद्वारे Guido शी चर्चा केली. आम्ही व्हेरिएबल्ससाठी टाईप टिप्पण्या वापरण्याचे ठरवले. याने इच्छित उद्देश पूर्ण केला, परंतु काहीसा त्रासदायक होता (पायथन ३.६ ने आम्हाला एक छान वाक्यरचना दिली):

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

Python 2 ला समर्थन देण्यासाठी टाइप टिप्पण्या देखील उपयुक्त आहेत, ज्यात टाइप भाष्यांसाठी अंगभूत समर्थन नाही:

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

असे दिसून आले की या (आणि इतर) ट्रेड-ऑफने खरोखर काही फरक पडत नाही - स्थिर टायपिंगच्या फायद्यांचा अर्थ असा होतो की वापरकर्ते लवकरच कमी-परिपूर्ण वाक्यरचना विसरले. टाइप-चेक केलेल्या पायथन कोडमध्ये कोणतीही विशेष सिंटॅक्टिक रचना वापरली नसल्यामुळे, विद्यमान पायथन टूल्स आणि कोड प्रोसेसिंग प्रक्रिया सामान्यपणे कार्य करत राहिल्या, ज्यामुळे विकसकांना नवीन टूल शिकणे खूप सोपे होते.

मी माझा ग्रॅज्युएट प्रबंध पूर्ण केल्यानंतर मला ड्रॉपबॉक्समध्ये सामील होण्यासही गुइडोने खात्री दिली. येथूनच मायपी कथेचा सर्वात मनोरंजक भाग सुरू होतो.

पुढे चालू…

प्रिय वाचक! तुम्ही Python वापरत असल्यास, कृपया या भाषेत तुम्ही विकसित केलेल्या प्रकल्पांच्या स्केलबद्दल आम्हाला सांगा.

स्त्रोत: www.habr.com