पाइलिंट अंदर से बाहर। वह कैसे करता है

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

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

हमें Pylint की आवश्यकता क्यों है?

यदि आप पहले से ही इसका उपयोग करते हैं, तो यह सवाल उठ सकता है: "क्यों पता है कि पाइलिंट के अंदर क्या है, यह ज्ञान कैसे मदद कर सकता है?"

आमतौर पर, डेवलपर्स कोड लिखते हैं, लिंटर को लॉन्च करते हैं, सुधार के बारे में संदेश प्राप्त करते हैं कि कोड को और अधिक सुंदर कैसे बनाया जाए, और प्रस्तावित परिवर्तन करें। अब कोड पढ़ना आसान है और सहयोगियों को दिखाने में शर्म नहीं।

लंबे समय तक, उन्होंने सियान इंस्टीट्यूट में पाइलिंट के साथ ठीक उसी तरह से काम किया, जिसमें मामूली जोड़-घटाव था: उन्होंने कॉन्फ़िगरेशनों को बदल दिया, अनावश्यक नियमों को हटा दिया और अधिकतम स्ट्रिंग लंबाई बढ़ा दी।

लेकिन कुछ बिंदु पर वे एक समस्या में भाग गए, जिसके लिए मुझे पाइलिंट में गहरी खुदाई करनी पड़ी और यह पता लगाना पड़ा कि यह कैसे काम करता है। यह समस्या क्या है और इसे कैसे हल किया जाए, इस पर पढ़ें।


स्पीकर के बारे में: मैक्सिम माज़ेव ( बैकस्लैश ), 5 साल के विकास में, CIAN में काम करता है। गहराई से पायथन, अतुल्यकालिक और कार्यात्मक प्रोग्रामिंग सीखता है।

सियान के बारे में

ज्यादातर का मानना ​​है कि कियान रियल एस्टेट के साथ एक रियल एस्टेट एजेंसी है और वे बहुत आश्चर्यचकित होते हैं जब उन्हें पता चलता है कि रियलटर्स के बजाय हमारे पास प्रोग्रामर हैं।

हम एक तकनीकी कंपनी हैं, जिसमें कोई भी रिएक्टर नहीं हैं, लेकिन बहुत सारे प्रोग्रामर हैं।

• प्रति दिन 1 मिलियन अद्वितीय उपयोगकर्ता।
• मास्को और सेंट पीटर्सबर्ग में अचल संपत्ति की बिक्री और किराये के लिए सबसे बड़ा बुलेटिन बोर्ड। 2018 में, उन्होंने संघीय स्तर पर प्रवेश किया और पूरे रूस में काम किया।
• विकास टीम में लगभग 100 लोग हैं, जिनमें से 30 दैनिक पायथन कोड लिखते हैं।

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

• सभ्य गुणवत्ता का कोड।
• शैलीगत समरूपता। सभी डेवलपर्स को रिपॉजिटरी में "विनैग्रेट" के बिना लगभग समान कोड लिखना चाहिए।

इसे प्राप्त करने के लिए, निश्चित रूप से, आपको एक कोड समीक्षा की आवश्यकता है।

कोड समीक्षा

CIAN में कोड समीक्षा दो चरणों में होती है:

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

कोड समीक्षा मुद्दे

पुल अनुरोध के कारण कोड समीक्षा पास नहीं हो सकती है:

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

यदि लाइनर कोड की जांच करता है तो स्टाइल की समस्याएं क्या हो सकती हैं?

पायथन में लिखने वाले हर कोई जानता है कि पीईपी -8 कोड लिखने के लिए एक गाइड है। किसी भी मानक की तरह, PEP-8 बहुत सामान्य है और हमारे लिए, डेवलपर्स के रूप में, यह पर्याप्त नहीं है। मैं कुछ स्थानों में मानक निर्दिष्ट करना चाहता हूं, और दूसरों में विस्तार करना चाहता हूं।

इसलिए, हम अपनी आंतरिक व्यवस्था के साथ आए कि कैसे कोड को देखना चाहिए और काम करना चाहिए, और उन्हें "अस्वीकृत सेलियन प्रस्ताव" कहा ।



"नियत Cian प्रस्ताव" - नियमों का एक सेट, अब लगभग 15. हैं। इनमें से प्रत्येक नियम को अस्वीकार किए जाने वाले पुल अनुरोध के लिए आधार है और संशोधन के लिए भेजा गया है।

उत्पादक कोड की समीक्षा में क्या बाधा है?

हमारे आंतरिक नियमों के साथ एक समस्या है - लिंटर उनके बारे में नहीं जानता है, और यह अजीब होगा अगर वह जानता था - वे आंतरिक हैं।

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

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

हम इस समस्या से छुटकारा पाना चाहेंगे।

लेकिन हमें अपना लिंटर मत लिखो?

ऐसा लगता है कि समस्या को एक उपकरण द्वारा हल किया जाएगा जो सभी आंतरिक समझौतों के बारे में जानता होगा और उनके कार्यान्वयन के लिए कोड की जांच करने में सक्षम होगा। तो हम अपने खुद के लिंटर की जरूरत है?

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

तो अगर हम अपना लिंटर लिखना नहीं चाहते हैं तो समस्या को कैसे हल करें?

पाइलिंट प्लगिन लिखें

आप पाइलिंट के लिए प्लगइन्स लिख सकते हैं, उन्हें चेकर्स कहा जाता है। प्रत्येक आंतरिक नियम के तहत, आप अपना खुद का चेकर लिख सकते हैं, जो इसे जांचेगा।

ऐसे चेकर्स के दो उदाहरणों पर विचार करें।

उदाहरण संख्या १

कुछ बिंदु पर, यह पता चला कि कोड में "TODO" फ़ॉर्म की कई टिप्पणियां शामिल हैं - रिफ्लेक्टर का वादा करता है, अनावश्यक कोड हटाता है या इसे खूबसूरती से फिर से लिखता है, लेकिन अभी नहीं, लेकिन बाद में। ऐसी टिप्पणियों के साथ एक समस्या है - वे बिल्कुल आपको किसी चीज के लिए उपकृत नहीं करते हैं।

समस्या

डेवलपर ने एक वादा लिखा, बहिष्कृत किया और अगले कार्य को करने के लिए मन की शांति के साथ चला गया।


संक्षेप में:

• वादों के साथ टिप्पणियाँ वर्षों से लटकी हुई हैं और उनका पालन नहीं किया जाता है;
• कोड अटे पड़े हैं;
• तकनीकी ऋण वर्षों से जमा हुआ है।

उदाहरण के लिए, 3 साल पहले एक डेवलपर ने सफल रिलीज के बाद कुछ हटाने का वादा किया था, लेकिन क्या रिलीज 3 साल में हुई? शायद हाँ। क्या मुझे इस मामले में कोड हटाना चाहिए? यह एक बड़ा सवाल है, लेकिन सबसे अधिक संभावना नहीं है।

समाधान: Pylint के लिए अपना चेकर लिखें

आप डेवलपर्स को ऐसी टिप्पणियां लिखने से मना नहीं कर सकते, लेकिन आप उन्हें अतिरिक्त काम करने के लिए तैयार कर सकते हैं: वादे को अंतिम रूप देने के लिए ट्रैकर में एक कार्य बनाएं। फिर हम निश्चित रूप से उसके बारे में नहीं भूलेंगे।

हमें TODO फ़ॉर्म की सभी टिप्पणियों को खोजने और यह सुनिश्चित करने की आवश्यकता है कि उनमें से प्रत्येक का जीरा में एक कार्य के लिए लिंक है। लिखते हैं।

Pylint के संदर्भ में एक चेकर क्या है? यह एक वर्ग है जो चेकर के आधार वर्ग से विरासत में मिलता है और एक निश्चित इंटरफ़ेस को लागू करता है।

class TodoIssueChecker(BaseChecker): _ _implements_ _ = IRawChecker 

हमारे मामले में, यह IRawChecker है - तथाकथित "कच्चा" चेकर।

एक कच्चा चेकर एक फ़ाइल की तर्ज पर पुनरावृति करता है और एक लाइन पर एक निश्चित कार्रवाई कर सकता है। हमारे मामले में, प्रत्येक पंक्ति पर, चेकर एक टिप्पणी और एक कार्य के लिए लिंक के समान कुछ की तलाश करेगा।

चेकर के लिए, आपको उन संदेशों की सूची निर्धारित करनी होगी जो इसे जारी करेंगे:

 msgs = { '9999': ('  TODO    ', issue-code-in-todo', ' ')} 

संदेश में है:

• वर्णन छोटा और लंबा है;
• चेकर कोड और एक छोटा मेनेमोनिक नाम जो यह निर्धारित करता है कि यह किस प्रकार का संदेश है।

संदेश कोड में "C1234" रूप है, जिसमें:

• पहला पत्र स्पष्ट रूप से विभिन्न प्रकार के संदेशों के लिए मानकीकृत है: [सी] आविष्कार; [डब्ल्यू] arning; [ई] योग; [एफ] अटल; [आर] efactoring। पत्र के लिए धन्यवाद, रिपोर्ट तुरंत दिखाती है कि क्या हो रहा है: समझौतों की याद दिलाने या घातक समस्याओं को तत्काल संबोधित करने की आवश्यकता है।
• 4 यादृच्छिक संख्या Pylint के लिए अद्वितीय।

यदि यह अनावश्यक हो जाता है तो चेक को निष्क्रिय करने के लिए कोड की आवश्यकता होती है। आप पाइलिंट लिख सकते हैं: अक्षम करें और एक छोटा अल्फ़ान्यूमेरिक कोड या नाममात्र का नाम:

 # Pylint: disable=C9999 # Pylint: disable=issue-code-in-todo 

Pylint के लेखकों ने अल्फ़ान्यूमेरिक कोड को छोड़ने और mnemonic का उपयोग करने की सलाह दी है, यह अधिक दृश्य है।

अगला कदम process_module नामक एक विधि को परिभाषित करना है ।



नाम बहुत महत्वपूर्ण है। विधि को उस तरह से बुलाया जाना चाहिए, क्योंकि पाइलिंट फिर इसे कॉल करेगा।

नोड पैरामीटर मॉड्यूल को पारित किया जाता है। इस मामले में, इससे कोई फर्क नहीं पड़ता कि यह क्या है या यह किस प्रकार का है, यह याद रखना केवल महत्वपूर्ण है कि नोड में एक स्ट्रीम विधि है जो फ़ाइल लाइन को लाइन द्वारा लौटाता है।

आप फ़ाइल के माध्यम से जा सकते हैं और प्रत्येक पंक्ति के लिए टिप्पणियों और कार्यों के लिंक की जांच कर सकते हैं। यदि कोई टिप्पणी है, लेकिन कोई लिंक नहीं है, तो चेकर कोड और लाइन नंबर के साथ फॉर्म 'इश्यू-कोड-टू-टू' फॉर्म की चेतावनी फेंक दें। एल्गोरिथ्म काफी सरल है।

चेकर को पंजीकृत करें ताकि पाइलिंट इसके बारे में जान सके। यह रजिस्टर फ़ंक्शन द्वारा किया जाता है:

 def register(linter: Pylinter) -> None: linter. register_checker ( TodoIssueChecker(linter) ) 

• Pylint का एक उदाहरण फंक्शन में आता है।
• यह register_checker विधि को कॉल करता है।
• हम चेकर को विधि से पास करते हैं।

एक महत्वपूर्ण बिंदु: चेकर मॉड्यूल PYTHONPATH में होना चाहिए ताकि Pylint इसे बाद में आयात कर सके।

एक पंजीकृत परीक्षक को कार्यों के लिंक के बिना टिप्पणियों के साथ एक परीक्षण फ़ाइल द्वारा जाँच की जाती है।

 $ cat work. # T0D0:   , -! $ pylint work. --load-plugins todo_checker … 

परीक्षण के लिए, पाइलिंट चलाएं, मॉड्यूल को इसमें पास करें, लोडर -प्लगइन्स पैरामीटर का उपयोग करके चेकर को पास करें, और लिंटर के अंदर, दो चरण चलाएं।

चरण 1. प्लगइन प्रारंभिक

• प्लगइन्स वाले सभी मॉड्यूल आयात किए जाते हैं। पाइलिंट में आंतरिक और बाहरी चेकर्स हैं। वे सभी एक साथ आते हैं और आयात किए जाते हैं।
• हम रजिस्टर करते हैं - मॉड्यूल.ग्रिस्टर (स्व) । प्रत्येक चेकर के लिए, रजिस्टर फ़ंक्शन को कहा जाता है, जहां पाइलिंट का उदाहरण दिया जाता है।
• चेक किए जाते हैं: सही प्रारूप में संदेशों, विकल्पों और रिपोर्टों की उपस्थिति के लिए मापदंडों की वैधता के लिए।

चरण 2. चेकर्स के पूल को पार्स करें

चरण 1 के बाद, विभिन्न प्रकार के चेकर्स की पूरी सूची बनी हुई है:

• एएसटी चेकर;
• कच्चा चेकर;
• टोकन चेकर।

सूची से हम उन लोगों का चयन करते हैं जो कच्चे चेकर इंटरफ़ेस से संबंधित हैं: हम देखते हैं कि कौन से चेकर्स IRawChecker इंटरफ़ेस को लागू करते हैं और उन्हें अपने लिए लेते हैं।

प्रत्येक चयनित चेकर के लिए, checker.process_module (मॉड्यूल) विधि को कॉल करें, और चेक चलाएँ।

परिणाम

जाँचकर्ता को फिर से परीक्षण फ़ाइल पर चलाएँ:

 $ cat work. # T0D0:   , -! $ pylint work,  --load-plugins todo_checker : 0,0:   T0D0     (issue-code-in-todo) 

एक संदेश बताता है कि TODO के साथ एक टिप्पणी है और कार्य के लिए कोई लिंक नहीं है।

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

उदाहरण संख्या 2. खोजशब्द-तर्क

ऐसे कार्य हैं जो स्थितिगत तर्क देते हैं। यदि बहुत सारे तर्क हैं, तो जब वे फ़ंक्शन को कॉल करते हैं, तो यह बहुत स्पष्ट नहीं है कि तर्क कहां है और इसकी आवश्यकता क्यों है।

समस्या

उदाहरण के लिए, हमारे पास एक फ़ंक्शन है:

 get_offer_by_cian_id( "sale", rue, 859483, ) 

कोड में बिक्री और ट्रू है, और यह स्पष्ट नहीं है कि उनका क्या मतलब है। यह बहुत सुविधाजनक है जब फ़ंक्शन जिसमें कई तर्क हैं, केवल नामित तर्कों के साथ कहा जाएगा:

 get_offer_by_cian_id( deal_type="sale", truncate=True, cian_id=859483, ) 

यह एक अच्छा कोड है, जिसमें यह तुरंत स्पष्ट हो जाता है कि कौन सा पैरामीटर कहां है और हम उनके अनुक्रम को भ्रमित नहीं करेंगे। आइए एक चेकर लिखने की कोशिश करें जो ऐसे मामलों की जांच करता है।

पिछले उदाहरण में उपयोग किए गए "कच्चे" चेकर को ऐसे मामले के लिए लिखना बहुत मुश्किल है। आप सुपर-कॉम्प्लेक्स रेगुलर एक्सप्रेशन जोड़ सकते हैं, लेकिन इस तरह के कोड को पढ़ना मुश्किल है। यह अच्छा है कि Pylint AST सार सिंटैक्स ट्री के आधार पर दूसरे प्रकार के चेकर को लिखना संभव बनाता है, और हम इसका उपयोग करेंगे।

एएसटी के बारे में गीत

एएसटी या एब्स्ट्रैक्ट सिंटेक्स ट्री कोड का एक पेड़ प्रतिनिधित्व है, जहां शीर्ष ऑपरेट्स है और पत्तियां ऑपरेटर हैं।

उदाहरण के लिए, एक फ़ंक्शन कॉल, जहां एक स्थिति तर्क और दो नामित तर्क होते हैं, एक सार पेड़ में बदल जाता है:


टाइप कॉल के साथ एक शीर्ष है और इसमें निम्न है:

• फ़ंक्शन विशेषताओं को फंक कहा जाता है;
• स्थिति संबंधी तर्कों की एक सूची, जहां प्रकार कांस्ट के साथ एक नोड है और 112 का मूल्य है;
• नामित तर्कों की सूची कीवर्ड।

इस मामले में कार्य:

• मॉड्यूल में सभी प्रकार के कॉल (फ़ंक्शन कॉल) के साथ नोड्स ढूंढें।
• फ़ंक्शन द्वारा ली गई तर्कों की कुल संख्या की गणना करें।
• यदि 2 से अधिक तर्क हैं, तो सुनिश्चित करें कि नोड में कोई स्थितिगत तर्क नहीं हैं।
• यदि स्थितिगत तर्क हैं, तो एक चेतावनी दिखाएं।

 ll( func=Name(name='get_offer'), args=[Const(value=1298880)], keywords=[ … ]))] 

पाइलिंट के दृष्टिकोण से, एएसटी-आधारित चेकर एक वर्ग है जो बेस चेकर वर्ग से विरासत में मिलता है और आईएस्ट्रोइड कैचर इंटरफ़ेस लागू करता है:

 class NonKeywordArgsChecker(BaseChecker): -_ _implements_ _ = IAstroidChecker 

जैसा कि पहले उदाहरण में, संदेश सूची में चेकर विवरण, संदेश कोड, लघु mnemonic नाम दर्शाया गया है:

 msgs = { '9191': (' ', keyword-only-args', ' ')} 

अगला चरण visit_call विधि को परिभाषित करना है:

 def visit_call(self, node: Call) … 

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

• एएसटी पार्सर पेड़ के माध्यम से चलता है और प्रत्येक शीर्ष के लिए यह देखने के लिए दिखता है कि क्या चेकर का दौरा_ <नाम> इंटरफ़ेस परिभाषित है।
• यदि ऐसा है, तो इसे कॉल करें।
• पुन: अपने सभी बच्चों के साथ गुजरता है।
• नोड छोड़ते समय, इसे लीव_ <नाम> विधि कहा जाता है।

इस उदाहरण में, visit_call विधि एक इनपुट के रूप में कॉल-टाइप नोड प्राप्त करेगी और देखें कि क्या इसमें दो से अधिक तर्क हैं और क्या स्थिति संबंधी तर्क एक चेतावनी फेंकने के लिए मौजूद हैं और नोड को ही कोड पास करना है।

 def visit_call(self, n): if node.args and len(node.args + node.keywords) > 2: self.add_message( 'keyword-only-args', node=node ) 

हम पिछले उदाहरण के रूप में, चेकर को पंजीकृत करते हैं: हम पाइलिंट उदाहरण को स्थानांतरित करते हैं, रजिस्टर_चेकर को कॉल करते हैं, चेकर को स्वयं पास करते हैं और इसे शुरू करते हैं।

 def register(linter: Pylinter) -> None: linter.register_checker( TodoIssueChecker(linter) ) 

यह एक परीक्षण फ़ंक्शन कॉल का एक उदाहरण है जहां 3 तर्क हैं और उनमें से केवल एक का नाम है:

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker … 

यह एक ऐसा कार्य है जो संभावित रूप से हमारे दृष्टिकोण से गलत रूप से कहा जाता है। पाइलिंट लॉन्च करें।

प्लगइन प्रारंभिक चरण 1 पूरी तरह से दोहराया गया है, जैसा कि पिछले उदाहरण में है।

चरण 2. एएसटी में मॉड्यूल पार्सिंग

कोड को AST ट्री में पार्स किया जाता है। विश्लेषण एस्ट्रोइड लाइब्रेरी द्वारा किया जाता है ।

एस्ट्रोइड, एएसटी (stdlib) क्यों नहीं

एस्ट्रॉयड आंतरिक रूप से मानक पायथन एएसटी मॉड्यूल का उपयोग नहीं करता है, लेकिन टाइप किए गए_स्टैट टाइप एएसटी पार्सर , जिसमें विशेषता है कि यह पीईपी 484 प्रकार के संकेत का समर्थन करता है। टाइप्ड_स्ट एएसटी की एक शाखा है, जो समानांतर में विकसित होती है। दिलचस्प है, वही कीड़े हैं जो एएसटी में हैं, और समानांतर में मरम्मत की जाती है।

 from module import Entity def foo(bar): # type: (Entity) -> None return 

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

GitHub के कुछ बिंदु पर, Guido Van Rossum एस्ट्रोइड में आए और कहा: "दोस्तों, आपके पास Pylint है जो ऐसे मामलों पर शपथ लेता है, और हमारे पास एक टाइप एएसटी पार्सर है जो इस सब का समर्थन करता है। चलो दोस्त हैं! ”

काम में उबाल आने लगा है! 2 साल बीत गए, इस वसंत Pylint ने टाइप एएसटी पार्सर पर स्विच किया और ऐसी चीजों पर शपथ लेना बंद कर दिया। Taiphints के लिए आयात अब अप्रयुक्त के रूप में चिह्नित नहीं हैं।

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

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

• एस्ट्रोइड को अमूर्त पेड़ को संशोधित करने और अजगर की गतिशील प्रकृति को समझने में मदद करें।
• उपयोगी जानकारी के साथ पूरक एएसटी।

एक विशिष्ट उदाहरण pylint-django है । जटिल डेंजो-मॉडल के साथ काम करते समय, लाइनर अक्सर अज्ञात विशेषताओं पर शपथ लेता है। Pylint-django बस इस समस्या का हल करता है।

चरण 3. चेकर्स के पूल को पार्स करें

हम तपाक से लौटे। हमारे पास फिर से चेकर्स की एक सूची है, जिसमें से हम उन लोगों को ढूंढते हैं जो एएसटी चेकर इंटरफेस को लागू करते हैं।

चरण 4. नोड्स के प्रकारों द्वारा पार्स चेकर्स

अगला, हम प्रत्येक चेकर के लिए तरीके खोजते हैं, वे दो प्रकार के हो सकते हैं:

• visit_ <नोड नाम>
• lev_ <नोड नाम>।

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

 _visit_methods = dict( < > : [checker1, checker2 ... checkerN] ) 

लीव-मेथड्स के साथ भी: नोड नाम के रूप में एक कुंजी, उन चेकर्स की सूची जो इस नोड से बाहर निकलने के तथ्य में रुचि रखते हैं।

 _leave_methods = dict( < >: [checker1, checker2 ... checkerN] ) 

पाइलिंट लॉन्च करें। यह एक चेतावनी दिखाता है कि हमारे पास एक फ़ंक्शन है जहां दो से अधिक तर्क हैं और इसमें एक स्थितिगत तर्क है:

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker C: 0, 0:  c >2      (keyword-only-args) 

समस्या हल हो गई है। अब, कोड समीक्षा प्रोग्रामर को फ़ंक्शन के तर्कों को पढ़ने की आवश्यकता नहीं है; लाइनर उनके लिए यह करेगा। हमने अपना समय बचाया , कोड समीक्षा के लिए समय और कार्य उत्पादन में तेजी से आगे बढ़ते हैं।

और परीक्षण लिखने के लिए?

Pylint आपको चेकर्स की यूनिट परीक्षण करने की अनुमति देता है और यह बहुत सरल है। लिंटर के दृष्टिकोण से, परीक्षण-परीक्षक एक वर्ग जैसा दिखता है जो अमूर्त CheckerTestCase से विरासत में मिला है । उस चेक को इंगित करना आवश्यक है जो उसमें जाँच की जा रही है।

 class TestNonKwArgsChecker(CheckerTestCase): CHECKER_CLASS = NonKeywordArgsChecker 

चरण 1. हम उस कोड के भाग से एक परीक्षण एएसटी-नोड बनाते हैं जिसे हम जाँच रहे हैं।

 node = astroid.extract_node( "get_offers(3, 'magic', 'args')" ) 

चरण 2. जाँचें कि चेकर, नोड में प्रवेश करता है, या तो फेंकता है या संबंधित संदेश को फेंकता नहीं है:

 with self.assertAddsMessages(message): self.checker.visit_call(node) 

TokenChecker

एक अन्य प्रकार का चेकर है जिसे टोकनकेचर कहा जाता है। यह एक शाब्दिक विश्लेषक के सिद्धांत पर काम करता है। पायथन में एक टोकन मॉड्यूल है जो एक लेक्सिकल स्कैनर का काम करता है और कोड को टोकन की सूची में तोड़ देता है। यह कुछ इस तरह दिख सकता है:


परिवर्तनीय नाम, फ़ंक्शन नाम और कीवर्ड टाइप NAME के ​​टोकन बन जाते हैं, और सीमांकक, कोष्ठक, कॉलन ओपी के प्रकार बन जाते हैं। इसके अलावा, इंडेंटेशन, लाइन फीड और रिवर्स ट्रांसलेशन के लिए अलग-अलग टोकन हैं।

Pylint TokenChecker के साथ कैसे काम करता है:

• परीक्षण के तहत मॉड्यूल टोकन है।
• टोकन की एक विशाल सूची सभी चेकर्स को दी जाती है जो ITokenChecker को लागू करते हैं और process_tokens (टोकन) विधि को कहते हैं ।

हमने टोकनकेचर का उपयोग नहीं पाया है, लेकिन कुछ उदाहरण हैं जो पाइलिंट उपयोग करता है:

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

निष्कर्ष

हमें कोड समीक्षा में समस्या थी। डेवलपर्स ने लिंटर का काम किया, व्यर्थ कोड स्कैनिंग पर अपना समय बिताया और लेखक को त्रुटियों के बारे में सूचित किया। Pylint के साथ हम:

• लाइनर को नियमित जाँच हस्तांतरित, उसमें आंतरिक समझौते लागू किए।
• वृद्धि की गति और गुणवत्ता कोड की समीक्षा।
• अस्वीकृत पुल अनुरोध की संख्या कम हो गई, और उत्पादन में कार्यों को पारित करने का समय कम हो गया है।

एक साधारण चेकर आधे घंटे में लिखा जाता है, और कुछ घंटों में एक जटिल। चेकर लिखने के लिए अधिक समय बचाता है और कई गैर-अस्वीकृत पुल अनुरोधों के लिए लड़ता है।

आप पाइलिंट के बारे में और आधिकारिक दस्तावेज में इसके लिए चेकर्स को कैसे लिखना है, इसके बारे में अधिक जान सकते हैं, लेकिन चेकर्स को लिखने के मामले में यह खराब है। उदाहरण के लिए, टोकनकेचर के बारे में वहाँ केवल एक उल्लेख है कि यह है, लेकिन चेकर को कैसे लिखना है, इसके बारे में नहीं। अधिक जानकारी GitHub पर Pylint स्रोतों में उपलब्ध है । आप देख सकते हैं कि मानक पैकेज में चेकर्स क्या हैं और अपना खुद का लिखने के लिए प्रेरित हों।

Pylint आंतरिक डिजाइन का ज्ञान मानव-घंटे बचाता है, सरल करता है
प्रदर्शन और कोड में सुधार। अपना समय बचाएं, अच्छा कोड लिखें और
लिंटर का उपयोग करें।

अगला मॉस्को पायथन कॉन्फ ++ सम्मेलन 5 अप्रैल, 2019 को आयोजित किया जाएगा और आप पहले से ही एक शुरुआती बिरफ टिकट बुक कर सकते हैं। अपने विचारों को इकट्ठा करना और एक रिपोर्ट के लिए आवेदन करना और भी बेहतर है, फिर यात्रा मुफ्त होगी, और रिपोर्ट के तैयारी पर कोचिंग सहित अच्छे बन्स एक बोनस के रूप में जाएंगे।

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