बड़े पैमाने पर पायथन परियोजनाओं में सख्त मॉड्यूल का उपयोग करना: इंस्टाग्राम अनुभव। भाग २

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

अंक 3: परस्पर वैश्विक स्थिति

सामान्य गलतियों की एक और श्रेणी पर एक नज़र डालें।

def myview(request):     SomeClass.id = request.GET.get("id") 

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

यही बात परीक्षणों में आसानी से हो सकती है। विशेष रूप से, ऐसे मामलों में जहां प्रोग्रामर बंदर पैच का उपयोग करने की कोशिश करते हैं और mock.patch तरह संदर्भ प्रबंधक का उपयोग नहीं करते हैं। इससे अनुरोधों का प्रदूषण नहीं हो सकता है, बल्कि एक ही प्रक्रिया में किए जाने वाले सभी परीक्षणों का प्रदूषण हो सकता है। यह हमारे परीक्षण प्रणाली के अविश्वसनीय व्यवहार का एक गंभीर कारण है। यह एक महत्वपूर्ण समस्या है, और इसे रोकना बहुत मुश्किल है। नतीजतन, हमने एकीकृत परीक्षण प्रणाली को त्याग दिया और एक परीक्षण अलगाव योजना में बदल दिया, जिसे "एक परीक्षण" प्रक्रिया के रूप में वर्णित किया जा सकता है।

दरअसल, यह हमारी तीसरी समस्या है। एक परिवर्तनशील वैश्विक स्थिति एक घटना है जो पायथन के लिए अद्वितीय नहीं है। आप इसे कहीं भी पा सकते हैं। हम मॉड्यूल या कक्षाओं से जुड़ी कक्षाओं, मॉड्यूल, सूचियों या शब्दकोशों के बारे में बात कर रहे हैं, जो मॉड्यूल स्तर पर बनाई गई सिंगलटन ऑब्जेक्ट्स के बारे में हैं। ऐसे वातावरण में काम करने के लिए अनुशासन की आवश्यकता होती है। कार्यक्रम चल रहा है, जबकि वैश्विक राज्य के प्रदूषण को रोकने के लिए, आपको पायथन के बहुत अच्छे ज्ञान की आवश्यकता है।

पेश है सख्त मॉड्यूल

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

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

हमारी समस्याओं के समाधान खोजने के लिए हमें एक विचार आया। इसमें सख्त मॉड्यूल का उपयोग किया जाता है।

सख्त मॉड्यूल एक नए प्रकार के पायथन मॉड्यूल हैं, जिसकी शुरुआत में एक निर्माण __strict__ = True । पायथन के पास पहले से मौजूद कई निम्न-स्तरीय विलुप्तता तंत्र का उपयोग करके उन्हें लागू किया जाता है। एक विशेष मॉड्यूल लोडर एस्ट्रो मॉड्यूल का उपयोग करके कोड को पार्स करता है, विश्लेषण करने के लिए लोड किए गए कोड की एक अमूर्त व्याख्या करता है, एएसटी के लिए विभिन्न परिवर्तनों को लागू करता है, और फिर निर्मित compile फ़ंक्शन का उपयोग करके एएसटी को वापस पायथन बाइटकोड में compile करता है।

कोई आयात साइड इफेक्ट नहीं

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

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

आइए इसे स्पष्ट करें, एक उदाहरण पर विचार करें। यहाँ सही ढंग से लिखा गया सख्त मॉड्यूल है:

 """Module docstring.""" __strict__ = True from utils import log_to_network MY_LIST = [1, 2, 3] MY_DICT = {x: x+1 for x in MY_LIST} def log_calls(func):    def _wrapped(*args, **kwargs):        log_to_network(f"{func.__name__} called!")        return func(*args, **kwargs)    return _wrapped @log_calls def hello_world():    log_to_network("Hello World!") 

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

लेकिन अगर हम log_to_network कॉल को बाहरी log_calls फ़ंक्शन पर ले गए, या यदि हमने किसी ऐसे डेकोरेटर का उपयोग करने की कोशिश की, जो साइड इफेक्ट्स (जैसे कि पिछले उदाहरण से @route ) के कारण होता है, या अगर हमने मॉड्यूल स्तर पर hello_world() कॉल का उपयोग किया है, तो यह सख्त होना बंद हो जाएगा मॉड्यूल।

यह कैसे पता करें कि मॉड्यूल स्तर पर log_to_network या route फ़ंक्शन को कॉल करना सुरक्षित नहीं है? हम इस धारणा से आगे बढ़ते हैं कि सख्त मॉड्यूल नहीं होने वाले मॉड्यूल से आयातित सब कुछ असुरक्षित है, मानक पुस्तकालय से कुछ कार्यों के अपवाद के साथ जिन्हें सुरक्षित माना जाता है। यदि utils मॉड्यूल एक सख्त मॉड्यूल है, तो हम अपने मॉड्यूल के विश्लेषण पर भरोसा कर सकते हैं ताकि हमें पता चल सके कि log_to_network फ़ंक्शन log_to_network ।

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

प्रतिरक्षा और __slots__ विशेषता

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

सख्त मॉड्यूल में घोषित वर्गों के सदस्यों को भी __init__ में घोषित किया जाना चाहिए। मॉड्यूल लोडर द्वारा किए गए एएसटी परिवर्तन के दौरान वे स्वचालित रूप से __slots__ विशेषता के लिए लिखे गए हैं। परिणामस्वरूप, बाद में आप वर्ग उदाहरण के लिए अतिरिक्त विशेषताएँ संलग्न नहीं कर सकते। यहाँ एक समान वर्ग है:

 class Person:    def __init__(self, name, age):        self.name = name        self.age = age 

एएसटी परिवर्तन के दौरान, जो सख्त मॉड्यूल के प्रसंस्करण के दौरान किया जाता है, __init__ में प्रदर्शन किए गए name और age गुणों को मान असाइन करने के संचालन का पता लगाया जाएगा, और __slots__ = ('name', 'age') एक गुण को क्लास में संलग्न किया जाएगा। यह किसी अन्य विशेषता को वर्ग के उदाहरण में जोड़े जाने से रोकेगा। (यदि प्रकार एनोटेशन का उपयोग किया जाता है, तो हम वर्ग स्तर पर उपलब्ध प्रकारों के बारे में जानकारी लेते हैं, जैसे कि name: str , और उन्हें स्लॉट की सूची में भी जोड़ते हैं)।

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

परिणाम

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

प्रिय पाठकों! क्या आपको लगता है कि सख्त मॉड्यूल द्वारा दी जाने वाली सुविधाएँ आपके पायथन प्रोजेक्ट में काम आती हैं?