एकल पायथन नामस्थान में कई पैकेजों को संयोजित करना

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

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

आइए देखें कि यह पायथन के विभिन्न संस्करणों में कैसे किया जा सकता है, हालांकि पायथन 2 अब जल्द ही समर्थित नहीं है, हम में से कई अभी दो आग के बीच हैं, और यह संक्रमण में महत्वपूर्ण बारीकियों में से एक है।



इस उदाहरण पर विचार करें:

हम पैकेज संरचना प्राप्त करना चाहते हैं:

namespace1 package1 module1 package2 module2 

मॉड्यूल 1 फ़ाइल सामग्री

 print('package 1') var1 = 1 

मॉड्यूल 2 सामग्री

 print('package 2') var2 = 2 

उसी समय, पैकेज निम्नलिखित फ़ोल्डर संरचना में वितरित किए जाते हैं:

  path1 namespace1 package1 module1 path2 namespace1 package2 module2 

मान लीजिए कि किसी तरह path1 और path2 को पहले ही sys.path में जोड़ दिया गया है। हमें मॉड्यूल 1 और मॉड्यूल 2 तक पहुंचने की आवश्यकता है:

  from namespace1.package1 import module1 from namespace1.package2 import module2 

जब इस कोड को निष्पादित किया जाता है तो Python 3.7 में क्या होता है? सब कुछ अद्भुत ढंग से काम करता है:

 package 1 package 2 

Python 3.3 में PEP-420 के साथ, निहित नामस्थानों का समर्थन दिखाई दिया है। इसके अलावा, py33 से पैकेज आयात करते समय, आपको __init__.py फाइलें बनाने की आवश्यकता नहीं है। और नामस्थान आयात करते समय, यह सिर्फ _ निषिद्ध_ है। यदि __init__.py फ़ाइल नाम name1 के साथ एक या दोनों निर्देशिकाओं में मौजूद है, तो दूसरे पैकेज के आयात पर एक त्रुटि होगी।

 ModuleNotFoundError: No module named 'namespace1.package2' 

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

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

 from pkgutil import extend_path __path__ = extend_path(__path__, __name__) 

इससे क्या होता है? जब दुभाषिया पहले आयात पर पहुंचता है, तो sys.path में समान नाम वाला एक पैकेज खोजा जाता है, यह path1 / namespace1 में होता है और दुभाषिया path1 / namespace1 / __ init__.py निष्पादित करता है। आगे की खोज नहीं की गई है। हालाँकि, Extended_path फ़ंक्शन स्वयं सभी sys.path पर एक खोज करता है, namepace1 और आंतरिक नाम के साथ सभी पैकेज पाता है और उन्हें संकुल namespace1 के __path__ चर में जोड़ता है, जिसका उपयोग इस नामस्थान में बाल पैकेज खोजने के लिए किया जाता है।

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

यह भविष्य के संस्करणों में काम करेगा और इस कोड का उपयोग संगत कोड लिखने के लिए किया जा सकता है, लेकिन ध्यान रखें कि आपको हर वितरित पैकेज में चुनी हुई विधि का पालन करना होगा। यदि संस्करण 3 पर आप कुछ पैकेजों में pkgutil.extend_path को कॉल करते हैं, और इन-बॉक्स के बिना कुछ छोड़ देते हैं, तो यह काम नहीं करेगा।
इसके अलावा, यह विकल्प उस स्थिति के लिए भी उपयुक्त है, जब आप python setup.py का उपयोग कर स्थापित करने की योजना बनाते हैं।

एक और तरीका, जिसे अब कुछ पुराना माना जाता है, लेकिन यह अभी भी बहुत कुछ पाया जा सकता है:

 #namespace1/__init__.py __import__('pkg_resources').declare_namespace(__name__) 

Pkg_resource मॉड्यूल सेटपूल के पैकेज के साथ आता है। यहाँ अर्थ pkgutil के समान है - यह आवश्यक है कि namespace1 के प्रत्येक स्थान पर प्रत्येक __init__ फ़ाइल में समान नामस्थान घोषणा शामिल है और कोई अन्य कोड नहीं है। उसी समय, सेटअप नाम में नेमस्पेस नामस्थान_पैकेज = ['नामस्थान 1'] दर्ज करना आवश्यक है। पैकेज बनाने का अधिक विस्तृत विवरण इस लेख के दायरे से परे है।

इसके अलावा, आप अक्सर ऐसा कोड पा सकते हैं

 try: __import__('pkg_resources').declare_namespace(__name__) except: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) 

यहां तर्क सरल है - अगर सेटप्टूल स्थापित नहीं हैं, तो हम pkgutil का उपयोग करते हैं, जो मानक पुस्तकालय में शामिल है।

यदि आप इन तरीकों में से किसी एक नाम स्थान को कॉन्फ़िगर करते हैं, तो आप एक मॉड्यूल से दूसरे को कॉल कर सकते हैं। उदाहरण के लिए, नामस्थान 1 / पैकेज 2 / मॉड्यूल 2 बदलें

 import namespace1.package1.module1 print(var1) 

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

 namespace1 package1 module1 package1 module2 

इस स्थिति में, केवल पहला आयात किया जाएगा और मॉड्यूल 2 तक कोई पहुंच नहीं होगी। पैकेज संयुक्त नहीं हो सकते।

 from namespace1.package1 import module1 from namespace1.package1 import module2 #>>ImportError: cannot import name module2 

सारांश:

1. 3.3 से अधिक उम्र के और पाइप के साथ स्थापित करने के लिए, यह अनुशंसा की जाती है कि आप एक अनुमानित नाम स्थान घोषणा का उपयोग करें।
2. संस्करण 2 और 3 के समर्थन के मामले में, साथ ही साथ पाइप और पाइथन सेटअप थिंकपैड दोनों स्थापित होने से, pkgutil के साथ विकल्प की सिफारिश की जाती है।
3. यदि आपको इस पद्धति का उपयोग करके पुराने पैकेजों का समर्थन करने की आवश्यकता है, या आपको zip-safe होने के लिए पैकेज की आवश्यकता है, तो pkg_resource विकल्प की सिफारिश की जाती है।

सूत्रों का कहना है:

• packaging.python.org/guides/packaging-namespace-packages
• www.python.org/dev/peps/pep-0420
• लर्निंग पाइथन, मार्क लुत्ज़ द्वारा 5 वां संस्करण

उदाहरण यहां देखे जा सकते हैं ।