सब कुछ टाइप करें

सभी को नमस्कार!

हमारे पास पहले से ही एक लेख है जो कि Ostrovok.ru में टाइपिंग के विकास के बारे में है। यह बताता है कि हम क्यों टाइप करने के लिए pyContracts से स्विच कर रहे हैं, क्यों हम टाइपगार्ड पर स्विच कर रहे हैं और हम किस चीज के साथ समाप्त हो रहे हैं। और आज मैं आपको इसके बारे में अधिक बताऊंगा कि यह संक्रमण कैसे होता है।

PyContracts के साथ एक फ़ंक्शन घोषणा आम तौर पर इस तरह दिखती है:

from contracts import new_contract import datetime @new_contract def User (x): from models import User return isinstance(x, User) @new_contract def dt_datetime (x): return isinstance(x, datetime.datetime) @contract def func(user_list, amount, dt=None): """ :type user_list: list(User) :type amount: int|float :type dt: dt_datetime|None :rtype: bool """ … 

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

और यह टाइपगार्ड के साथ वांछित परिणाम है:

 from typechecked import typechecked from typing import List, Optional, Union from models import User import datetime @typechecked def func (user_list: List[User], amount: Union[int, float], dt: Optional[datetime.datetime]=None) -> bool: ... 

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

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

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

मैपिंग बनाने के लिए स्क्रिप्ट का तर्क:

चरण 1. परियोजना की सभी फाइलों के माध्यम से जाओ, उन्हें पढ़ें। प्रत्येक फ़ाइल के लिए:

• यदि विकल्प "@new_contract" मौजूद नहीं है, तो इस फ़ाइल को छोड़ दें,
• अगर वहाँ है, तो फ़ाइल को "@new_contract" लाइन से विभाजित करें। प्रत्येक आइटम के लिए:
  - परिभाषा और आयात के लिए पार्स,
  - सफल होने पर, सफलता की फाइल पर लिखें,
  - यदि नहीं, तो त्रुटि फ़ाइल पर लिखें।

चरण 2. मैन्युअल रूप से प्रक्रिया त्रुटियों

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

1. यह एक कमांड है जो एक मॉड्यूल नाम को एक तर्क के रूप में लेता है (कई का उपयोग किया जा सकता है), जिसमें फ़ंक्शन एनोटेशन के सिंटैक्स को प्रतिस्थापित किया जाना चाहिए।
2. सभी मॉड्यूल फ़ाइलों के माध्यम से जाओ, उन्हें पढ़ें। प्रत्येक फ़ाइल के लिए:
   
   • यदि कोई "@ कॉन्ट्रैक्ट" विकल्प नहीं है, तो इस फ़ाइल को छोड़ दें;
   • यदि हां, तो कोड को एस्ट्रो (सार सिंटैक्स ट्री) में बदल दें;
   • उन सभी कार्यों को खोजें जो प्रत्येक के लिए अनुबंध सज्जाकार के अधीन हैं:
     
     • डॉकस्ट्रिंग, पार्स, तब हटाएं,
     • प्रपत्र {arg_name: arg_type} का एक शब्दकोश बनाएं, फ़ंक्शन एनोटेशन को बदलने के लिए इसका उपयोग करें,
     • नया आयात याद रखें,
   • एस्टनपर्स के माध्यम से एक फ़ाइल में संशोधित पेड़ लिखें;
   • फ़ाइल के शीर्ष पर नए आयात जोड़ें;
   • लाइनों को "@ कॉन्ट्रेक्ट" के साथ "@typechecked" से बदलें क्योंकि यह एस्ट्रो से आसान है।

प्रश्न हल करें "क्या यह नाम पहले से ही इस फ़ाइल में आयात किया गया है?" मेरा शुरू से इरादा नहीं था: इस समस्या के साथ हम आइसोर्ट लाइब्रेरी के एक अतिरिक्त रन के साथ सामना करेंगे।

लेकिन स्क्रिप्ट के पहले संस्करण को चलाने के बाद, सवाल उठे जो अभी भी हल होना था। यह पता चला है कि 1) ast सर्वशक्तिमान नहीं है, 2) astunparse हमसे ज्यादा सर्वशक्तिमान है जितना हम चाहेंगे। यह निम्नलिखित में प्रकट हुआ था:

• वाक्यविन्यास वृक्ष में संक्रमण के क्षण में, कोड से सभी एकल-पंक्ति टिप्पणियां गायब हो जाती हैं;
• खाली रेखाएं भी गायब हो जाती हैं;
• ast वर्ग के कार्यों और तरीकों में अंतर नहीं करता है, हमें तर्क जोड़ना था;
• इसके विपरीत, जब एक पेड़ से एक कोड पर स्विच किया जाता है, तो ट्रिपल उद्धरणों में बहु-पंक्ति टिप्पणियां एकल-उद्धरण टिप्पणियों में लिखी जाती हैं और एक पंक्ति पर कब्जा कर लेती हैं, और नई पंक्ति विराम को \ n द्वारा बदल दिया जाता है;
• अनावश्यक कोष्ठक दिखाई देते हैं, उदाहरण के लिए यदि ए और बी और सी या डी बन जाता है यदि (ए और बी और सी) या डी)।

Ast और astunparse के माध्यम से पारित कोड काम कर रहा है, लेकिन इसकी पठनीयता कम है।

उपरोक्त सबसे गंभीर दोष गायब एकल-लाइन टिप्पणियां हैं (अन्य मामलों में, हम कुछ भी नहीं खोते हैं, लेकिन केवल लाभ - कोष्ठक, उदाहरण के लिए)। Ast, astunparse, और tokenize पर आधारित भयावह पुस्तकालय यह पता लगाने का वादा करता है। वादा करता है और करता है।

अब खाली लाइनें। दो संभावित समाधान थे:

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

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

भयावहता में हम दो कार्यों का उपयोग करते हैं: पार्स और अवांछित, लेकिन दोनों आदर्श नहीं हैं - पार्स में अजीब आंतरिक त्रुटियां हैं, दुर्लभ मामलों में यह स्रोत कोड को पार्स नहीं कर सकता है, और अनपेक्षित कुछ ऐसा नहीं लिख सकता है जिसमें टाइप प्रकार हो (ऐसा प्रकार) यदि आप टाइप करते हैं (any_other_type))।

मैंने निर्णय किया कि मैं छद्म से नहीं निपटूंगा, क्योंकि काम का तर्क भ्रामक है, और अपवाद दुर्लभ हैं - गैर-सार्वभौमिकता का सिद्धांत यहां काम करता है।

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

1. लिखना - बस एक फ़ाइल के लिए कुछ लिखता है।
2. भर - इंडेंट की संख्या के आधार पर राइट का उपयोग करता है (इंडेंट की संख्या एक वर्ग क्षेत्र के रूप में संग्रहीत होती है)।
3. प्रवेश - इंडेंट बढ़ाता है।
4. छुट्टी - इंडेंट कम करता है।
5. प्रेषण - पेड़ के नोड के प्रकार को निर्धारित करता है (टी कहते हैं), नोड प्रकार के नाम से संबंधित विधि को कॉल करता है, लेकिन अंडरस्कोर (यानी _T) के साथ। यह एक मेटा विधि है।

अन्य सभी विधियां फॉर्म _T की विधियां हैं, उदाहरण के लिए, _Module या _Str। इस तरह की प्रत्येक विधि में, यह हो सकता है: 1) सबट्री नोड्स के लिए पुनरावर्ती भेज दें, या 2) नोड की सामग्री लिखने के लिए राइट का उपयोग करें या वर्ण और कीवर्ड जोड़ें ताकि परिणाम अजगर में एक वैध अभिव्यक्ति हो।

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

हमें प्रसंस्करण प्रकार की असंभवता की हमारी समस्या पर वापस लौटें। अब जब आप समझ गए हैं कि कैसे काम करता है, तो आपका प्रकार बनाना आसान है। चलो कुछ प्रकार बनाएँ:

 class NewType(object): def __init__ (self, t): self.s = ts 

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

ऐसा करने के लिए, horast.Unparser का विस्तार करें - अपने UnparserWithType को लिखें, जो कि horast.Unparser से विरासत में मिला है, और हमारे नए प्रकार की प्रोसेसिंग जोड़ें।

 class UnparserWithType(horast.Unparser): def _NewType (self, t): self.write(ts) 

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

और अब जादू बंदर पैच: हमारे UnparserWithType के साथ horast.Unparser को बदलें।

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

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

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

 class StrType(object): def __init__ (self, s, indent): self.s = s self.indent = indent def __repr__ (self): return '"""\n' + self.s + '\n' + ' ' * 4 * self.indent + '"""\n' 

रीप्र में हम परिभाषित करते हैं कि हमारी रेखा कैसी दिखनी चाहिए। मुझे लगता है कि यह एकमात्र समाधान से दूर है, लेकिन यह काम करता है। कोई astunparse.fill और astunparse.Unparser.indent के साथ प्रयोग कर सकता है, तो यह अधिक सार्वभौमिक होगा, लेकिन यह विचार इस लेख को लिखने के समय मेरे दिमाग में आया था।

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

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

मिली खामियों के बावजूद, स्क्रिप्ट वही करती है जो वह करने का इरादा रखती थी। परिणाम क्या है:

1. जिस समय के लिए परियोजना शुरू की गई है वह 10 से 3 सेकंड तक कम हो गई है;
2. नई_कंट्रेक्ट परिभाषाओं को हटाने के कारण फाइलों की संख्या में कमी आई है। फाइलें खुद ही कम हो गई थीं: मैंने माप नहीं किया था, लेकिन औसतन जीएटी कुल एन लाइनों और 2 एन हटाए गए;
3. स्मार्ट आईडीई ने अलग-अलग संकेत बनाने शुरू किए, क्योंकि अब वे टिप्पणी नहीं हैं, लेकिन ईमानदार आयात;
4. पठनीयता में सुधार हुआ है;
5. कहीं-कहीं कोष्ठक दिखाई दिए।

धन्यवाद!

उपयोगी लिंक:

1. Ast
2. Horast
3. सभी प्रकार के एस्ट्रो नोड्स और उनमें क्या संग्रहित है
4. खूबसूरती से वाक्य रचना पेड़ को दर्शाता है
5. Isort