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

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

→ मागील भाग: प्रथम и दुसरा

टाइप केलेल्या कोडच्या 4 दशलक्ष ओळींवर पोहोचणे

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

परिणामी, आमच्या सर्वात मोठ्या Python भांडारात (बॅकएंड कोडसह) जवळपास 4 दशलक्ष ओळी भाष्य केलेल्या कोड आहेत. स्टॅटिक कोड टायपिंगचे काम अंदाजे तीन वर्षांत पूर्ण झाले. Mypy आता विविध प्रकारच्या कोड कव्हरेज अहवालांना समर्थन देते ज्यामुळे टायपिंग प्रगतीचे निरीक्षण करणे सोपे होते. विशेषतः, आम्ही प्रकारांमध्ये अस्पष्टता असलेल्या कोडवर अहवाल तयार करू शकतो, उदाहरणार्थ, प्रकाराचा स्पष्ट वापर Any सत्यापित केले जाऊ शकत नाही अशा भाष्यांमध्ये, किंवा टाइप भाष्ये नसलेल्या तृतीय-पक्ष लायब्ररी आयात करण्यासारख्या गोष्टींसह. ड्रॉपबॉक्समधील प्रकार तपासणीची अचूकता सुधारण्याच्या प्रकल्पाचा एक भाग म्हणून, आम्ही केंद्रीकृत पायथन रेपॉजिटरीमधील काही लोकप्रिय मुक्त स्रोत लायब्ररींसाठी प्रकार व्याख्या (तथाकथित स्टब फाइल्स) सुधारण्यात योगदान दिले. टाइपशेड.

आम्ही काही विशिष्ट Python पॅटर्नसाठी अधिक अचूक प्रकारांना अनुमती देणारी प्रकार प्रणालीची नवीन वैशिष्ट्ये (आणि त्यानंतरच्या PEPs मध्ये प्रमाणित) लागू केली. याचे एक उल्लेखनीय उदाहरण आहे TypeDict, जे JSON-सारख्या शब्दकोषांसाठी प्रकार प्रदान करते ज्यात स्ट्रिंग कीचा निश्चित संच असतो, प्रत्येकाचे स्वतःचे मूल्य असते. आम्ही टाइप सिस्टमचा विस्तार करत राहू. आमची पुढील पायरी पायथनच्या संख्यात्मक क्षमतांसाठी समर्थन सुधारण्याची शक्यता आहे.

भाष्य केलेल्या कोडच्या ओळींची संख्या: सर्व्हर

भाष्य केलेल्या कोडच्या ओळींची संख्या: क्लायंट

भाष्य केलेल्या कोडच्या ओळींची एकूण संख्या

ड्रॉपबॉक्समध्ये भाष्य केलेल्या कोडचे प्रमाण वाढवण्यासाठी आम्ही केलेल्या मुख्य वैशिष्ट्यांचे विहंगावलोकन येथे आहे:

भाष्य कठोरता. नवीन कोड भाष्य करण्याच्या कठोरतेसाठी आम्ही हळूहळू आवश्यकता वाढवल्या. आम्‍ही लिंटर टिपांसह सुरुवात केली ज्यात आधीच काही भाष्ये असलेल्या फायलींवर भाष्ये जोडण्याची सूचना केली. आम्हाला आता नवीन पायथन फाइल्समध्ये आणि बर्‍याच अस्तित्वात असलेल्या फाइल्समध्ये टाईप भाष्ये आवश्यक आहेत.

अहवाल टाइप करणे. आम्ही संघांना त्यांच्या कोडमधील टायपिंगच्या स्तरावर साप्ताहिक अहवाल पाठवतो आणि प्रथम काय भाष्य करावे याबद्दल सल्ला देतो.

मायपीचे लोकप्रियीकरण. आम्ही इव्हेंटमध्ये mypy बद्दल बोलतो आणि टाईप एनोटेशन्ससह प्रारंभ करण्यात मदत करण्यासाठी टीमशी बोलतो.

मतदान. प्रमुख समस्या ओळखण्यासाठी आम्ही नियतकालिक वापरकर्ता सर्वेक्षण करतो. आम्ही या समस्यांचे निराकरण करण्यासाठी खूप पुढे जाण्यास तयार आहोत (अगदी मायपीला गती देण्यासाठी नवीन भाषा तयार करा!).

कामगिरी. आम्ही डिमन आणि mypyc वापरून mypy चे कार्यप्रदर्शन मोठ्या प्रमाणात सुधारले आहे. हे भाष्य प्रक्रियेदरम्यान उद्भवणाऱ्या गैरसोयी दूर करण्यासाठी आणि मोठ्या प्रमाणात कोडसह कार्य करण्यास सक्षम होण्यासाठी केले गेले.

संपादकांसह एकत्रीकरण. आम्ही ड्रॉपबॉक्सवर लोकप्रिय असलेल्या संपादकांमध्ये mypy चालवण्यास समर्थन देण्यासाठी साधने तयार केली आहेत. यामध्ये PyCharm, Vim आणि VS कोड समाविष्ट आहे. यामुळे कोडवर भाष्य करण्याची आणि त्याची कार्यक्षमता तपासण्याची प्रक्रिया मोठ्या प्रमाणात सुलभ झाली. विद्यमान कोड भाष्य करताना या प्रकारच्या क्रिया सामान्य आहेत.

स्थिर विश्लेषण. आम्ही स्थिर विश्लेषण साधनांचा वापर करून फंक्शन स्वाक्षरीचे अनुमान काढण्यासाठी एक साधन तयार केले आहे. हे साधन फक्त तुलनेने सोप्या परिस्थितींमध्येच काम करू शकते, परंतु याने आम्हाला आमचे कोड प्रकार कव्हरेज जास्त प्रयत्न न करता वाढवण्यास मदत केली.

तृतीय पक्ष लायब्ररीसाठी समर्थन. आमचे बरेच प्रकल्प SQLAlchemy टूलकिट वापरतात. हे Python च्या डायनॅमिक क्षमतेचा फायदा घेते की PEP 484 प्रकार थेट मॉडेल करू शकत नाहीत. आम्ही, PEP 561 नुसार, संबंधित स्टब फाइल तयार केली आणि mypy साठी प्लगइन लिहिले (मुक्त स्रोत), जे SQLAlchemy समर्थन सुधारते.

आम्हाला आलेल्या अडचणी

टाइप केलेल्या कोडच्या 4 दशलक्ष ओळींचा मार्ग आमच्यासाठी नेहमीच सोपा नसतो. या मार्गावर आम्हाला अनेक खड्डे पडले आणि अनेक चुका झाल्या. आम्हाला आलेल्या या काही समस्या आहेत. आम्हाला आशा आहे की त्यांच्याबद्दल सांगण्यामुळे इतरांना समान समस्या टाळण्यास मदत होईल.

गहाळ फायली. मोजक्याच फाईल्स तपासून आम्ही आमच्या कामाला सुरुवात केली. या फायलींमध्ये समाविष्ट नसलेली कोणतीही गोष्ट तपासली गेली नाही. प्रथम भाष्ये दिसल्यावर फाईल्स स्कॅनिंग सूचीमध्ये जोडल्या गेल्या. सत्यापनाच्या व्याप्तीच्या बाहेर असलेल्या मॉड्यूलमधून काहीतरी आयात केले असल्यास, आम्ही मूल्यांसह कार्य करण्याबद्दल बोलत होतो. Any, ज्याची अजिबात चाचणी झाली नाही. यामुळे टायपिंग अचूकतेचे लक्षणीय नुकसान झाले, विशेषत: स्थलांतराच्या सुरुवातीच्या टप्प्यात. या दृष्टिकोनाने आतापर्यंत आश्चर्यकारकपणे चांगले काम केले आहे, जरी एक सामान्य परिस्थिती अशी आहे की पुनरावलोकनाच्या व्याप्तीमध्ये फाइल्स जोडणे कोडबेसच्या इतर भागांमध्ये समस्या प्रकट करते. सर्वात वाईट परिस्थितीत, जेव्हा कोडचे दोन वेगळे क्षेत्र विलीन केले गेले, ज्यामध्ये, एकमेकांपासून स्वतंत्रपणे, प्रकार आधीच तपासले गेले होते, तेव्हा असे दिसून आले की या क्षेत्रांचे प्रकार एकमेकांशी विसंगत आहेत. त्यामुळे भाष्यांमध्ये अनेक बदल करण्याची गरज निर्माण झाली. आता मागे वळून पाहताना, आमच्या लक्षात येते की आम्ही मायपीच्या टाइप चेकिंग क्षेत्रामध्ये कोर लायब्ररी मॉड्यूल्स लवकर जोडले पाहिजेत. हे आमचे कार्य अधिक अंदाजे बनवेल.

जुन्या कोडवर भाष्य करत आहे. आम्ही सुरू केले तेव्हा, आमच्याकडे विद्यमान पायथन कोडच्या सुमारे 4 दशलक्ष ओळी होत्या. हे सर्व कोड टिपणे सोपे काम नव्हते हे स्पष्ट होते. आम्ही PyAnnotate नावाचे एक साधन तयार केले आहे जे चाचणी चालू असताना प्रकार माहिती गोळा करू शकते आणि गोळा केलेल्या माहितीच्या आधारे तुमच्या कोडमध्ये टाइप भाष्ये जोडू शकते. तथापि, आम्ही या साधनाचा विशेषतः व्यापक अवलंब लक्षात घेतलेला नाही. माहिती गोळा करणे धीमे होते आणि आपोआप व्युत्पन्न केलेल्या भाष्यांना अनेकदा अनेक मॅन्युअल संपादने आवश्यक असतात. जेव्हा आम्ही कोडचे पुनरावलोकन करतो तेव्हा प्रत्येक वेळी हे साधन स्वयंचलितपणे चालवण्याचा किंवा वास्तविक नेटवर्क विनंत्यांच्या काही लहान खंडांचे विश्लेषण करण्याच्या आधारे प्रकार माहिती गोळा करण्याचा विचार केला, परंतु दोन्हीपैकी एक मार्ग खूप धोकादायक असल्याने न करण्याचा निर्णय घेतला.

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

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

परिणाम: कोडच्या 5 दशलक्ष ओळी आणि नवीन क्षितिजांचा मार्ग

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

जरी ड्रॉपबॉक्समध्ये टाइप चेकिंग आधीच दिलेले असले तरी, मला विश्वास आहे की आम्ही अद्याप पायथन कोड टाइप करण्याच्या सुरुवातीच्या काळात आहोत. मला असे वाटते की प्रकार तपासण्याचे तंत्रज्ञान विकसित आणि सुधारत राहतील.

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

प्रिय वाचक! तुम्ही तुमच्या पायथन प्रोजेक्टमध्ये टाइप चेकिंग वापरता का?

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