👨‍🚀 🈲 ♿️ पायथन आयात स्वचालन 🛶 🗺️ 🕴🏽

को के बाद

को	के बाद
`import math import os.path import requests # 100500 other imports print(math.pi) print(os.path.join('my', 'path')) print(requests.get)`	`import smart_imports smart_imports.all() print(math.pi) print(os_path.join('my', 'path')) print(requests.get)`

import math import os.path import requests # 100500 other imports print(math.pi) print(os.path.join('my', 'path')) print(requests.get)

 import smart_imports smart_imports.all() print(math.pi) print(os_path.join('my', 'path')) print(requests.get)

ऐसा हुआ कि 2012 से मैं एक खुला स्रोत ब्राउज़र विकसित कर रहा हूं, केवल प्रोग्रामर होने के नाते। अजगर में ही। ब्राउज़र सबसे आसान चीज नहीं है, अब परियोजना के मुख्य भाग में 1000 से अधिक मॉड्यूल और 120,000 से अधिक पायनियर कोड हैं। कुल मिलाकर, यह उपग्रह परियोजनाओं के साथ डेढ़ गुना अधिक होगा।

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

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

उदाहरण के लिए, आपको math.pi पर पहुंचने के लिए import math लिखने की आवश्यकता नहीं होगी - हम math.pi समझ सकते हैं कि इस मामले में math मानक पुस्तकालय का एक मॉड्यूल है।

स्मार्ट आयात पायथन> = 3.5 का समर्थन करता है। पुस्तकालय पूरी तरह से परीक्षण, कवरेज> 95% द्वारा कवर किया गया है। अब मैं एक साल से इसका इस्तेमाल कर रहा हूं।

विवरण के लिए, मैं आपको कैट के लिए आमंत्रित करता हूं।

यह सामान्य रूप से कैसे काम करता है?

तो, हेडर इमेज से कोड निम्नानुसार काम करता है:

smart_imports.all() कॉल के दौरान smart_imports.all() लाइब्रेरी मॉड्यूल का एएसटी बनाता है जिसमें से कॉल किया जाता है;
अनियंत्रित चर का पता लगाएं;
हम प्रत्येक चर का नाम नियमों के अनुक्रम के माध्यम से चलाते हैं जो मॉड्यूल (या मॉड्यूल विशेषता) को खोजने की कोशिश करते हैं जो नाम से आयात के लिए आवश्यक है। यदि किसी नियम में आवश्यक इकाई पाई गई है, तो निम्न नियमों की जाँच नहीं की जाती है।
पाया गया मॉड्यूल वैश्विक नामस्थान (या इन मॉड्यूलों की आवश्यक विशेषताओं को वहां रखा गया है) में लोड, आरंभ और रखा गया है।

नए सिंटैक्स सहित सभी कोड में अनधिकृत चर खोजे जाते हैं।

ऑटो-आयात केवल उन प्रोजेक्ट घटकों के लिए सक्षम है जो स्पष्ट रूप से smart_imoprts.all() । इसके अलावा, स्मार्ट आयात का उपयोग पारंपरिक आयातों के उपयोग को प्रतिबंधित नहीं करता है। यह आपको लाइब्रेरी को धीरे-धीरे लागू करने की अनुमति देता है, साथ ही जटिल चक्रीय निर्भरता को भी हल करता है।

एक सावधानीपूर्वक पाठक यह नोटिस करेगा कि एएसटी मॉड्यूल का निर्माण दो बार किया गया है:

CPython इसे पहली बार मॉड्यूल आयात के दौरान बनाता है;
दूसरी बार smart_imports इसे एक कॉल के दौरान smart_imports.all() बनाता है।

एएसटी वास्तव में केवल एक बार बनाया जा सकता है (इसके लिए आपको PEP-0302 में लागू आयात हुक का उपयोग करके मॉड्यूल की आयात प्रक्रिया में एकीकृत करने की आवश्यकता है, लेकिन यह समाधान आयात को धीमा कर देता है।

आप ऐसा क्यों सोचते हैं?

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

बेशक, प्रत्येक मॉड्यूल का एएसटी लॉन्च के बाद केवल एक बार बनाया और विश्लेषण किया जाता है।

डिफ़ॉल्ट आयात नियम

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

नाम के सटीक संयोग से, यह चालू (अगले एक ही निर्देशिका में) मॉड्यूल के लिए खोज करता है।
मानक पुस्तकालय के मॉड्यूल की जाँच करता है:
- शीर्ष स्तर के संकुल के नाम के सटीक मिलान से;
- नेस्टेड पैकेज और मॉड्यूल के लिए, यौगिक नामों के लिए चेक, अंडरस्कोर के साथ डॉट्स की जगह। उदाहरण के लिए, यदि os_path चर os_path है, तो os_path आयात किया जाएगा।
नाम के सटीक मिलान से, यह स्थापित तृतीय-पक्ष पैकेज की खोज करता है। उदाहरण के लिए, प्रसिद्ध पैकेज अनुरोध ।

उत्पादकता

स्मार्ट आयात कार्यक्रम के प्रदर्शन को प्रभावित नहीं करता है, लेकिन लॉन्च होने में लगने वाले समय को बढ़ाता है।

एएसटी के पुनर्निर्माण के कारण, पहले रन का समय लगभग 1.52 गुना बढ़ जाता है। छोटी परियोजनाओं के लिए यह महत्वपूर्ण नहीं है। बड़ी परियोजनाओं में, स्टार्ट-अप का समय किसी विशेष मॉड्यूल के आयात समय के बजाय मॉड्यूल के बीच निर्भरता संरचना से ग्रस्त होता है।

जब स्मार्ट आयात लोकप्रिय हो जाता है, तो मैं एएसटी से सी तक के काम को फिर से लिखता हूं - इससे स्टार्टअप लागत को काफी कम करना चाहिए।

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

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

विन्यास

डिफ़ॉल्ट कॉन्फ़िगरेशन पहले वर्णित किया गया है। यह छोटी परियोजनाओं में मानक पुस्तकालय के साथ काम करने के लिए पर्याप्त होना चाहिए।

डिफ़ॉल्ट कॉन्फ़िगरेशन

 { "cache_dir": null, "rules": [{"type": "rule_local_modules"}, {"type": "rule_stdlib"}, {"type": "rule_predefined_names"}, {"type": "rule_global_modules"}] }

यदि आवश्यक हो, तो फ़ाइल सिस्टम पर एक अधिक जटिल कॉन्फ़िगरेशन डाला जा सकता है।

एक जटिल विन्यास का एक उदाहरण (एक ब्राउज़र से)।

smart_import.all() कॉल करने के दौरान smart_import.all() लाइब्रेरी फ़ाइल सिस्टम पर कॉलिंग मॉड्यूल की स्थिति निर्धारित करती है और वर्तमान निर्देशिका से रूट की दिशा में smart_imports.json फ़ाइल की तलाश शुरू करती है। यदि ऐसी कोई फ़ाइल मिलती है, तो इसे वर्तमान मॉड्यूल के लिए कॉन्फ़िगरेशन माना जाता है।

आप कई अलग-अलग कॉन्फ़िगरेशन (उन्हें अलग-अलग निर्देशिकाओं में रखकर) का उपयोग कर सकते हैं।

अब कई कॉन्फ़िगरेशन विकल्प नहीं हैं:

 { //     AST. //     null —   . "cache_dir": null|"string", //       . "rules": [] }

आयात नियम

कॉन्फ़िगरेशन में नियमों को निर्दिष्ट करने का क्रम उनके आवेदन का क्रम निर्धारित करता है। पहला नियम जिसने काम किया वह आयात के लिए आगे की खोज को रोकता है।

विन्यास के उदाहरणों में, नियम_प्रतिष्ठित_नाम नियम अक्सर rule_predefined_names दिखाई देगा, यह आवश्यक है कि अंतर्निहित फ़ंक्शन (उदाहरण के लिए, print ) सही रूप से पहचाने जाते हैं।

नियम 1: पूर्वनिर्धारित नाम

नियम आपको पूर्वनिर्धारित नामों जैसे __file__ और print जैसे अंतर्निहित कार्यों को अनदेखा करने की अनुमति देता है।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}] # } import smart_imports smart_imports.all() #        __file__ #        print(__file__)

नियम 2: स्थानीय मॉड्यूल

जाँचता है कि क्या वर्तमान मॉड्यूल (उसी निर्देशिका में) के बगल में निर्दिष्ट नाम के साथ एक मॉड्यूल है। अगर है, तो इसे आयात करें।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_local_modules"}] # } # #    : # # my_package # |-- __init__.py # |-- a.py # |-- b.py # b.py import smart_imports smart_imports.all() #    "a.py" print(a)

नियम 3: ग्लोबल मॉड्यूल

सीधे नाम से मॉड्यूल आयात करने की कोशिश करता है। उदाहरण के लिए, अनुरोध मॉड्यूल।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_global_modules"}] # } # #    # # pip install requests import smart_imports smart_imports.all() #    requests print(requests.get('http://example.com'))

नियम 4: कस्टम नाम

एक विशेष मॉड्यूल या इसकी विशेषता के नाम के अनुरूप है। नियम कॉन्फ़िगरेशन में अनुपालन इंगित किया गया है।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_custom", # "variables": {"my_import_module": {"module": "os.path"}, # "my_import_attribute": {"module": "random", "attribute": "seed"}}}] # } import smart_imports smart_imports.all() #       #        print(my_import_module) print(my_import_attribute)

नियम 5: मानक मॉड्यूल

जाँचता है कि क्या नाम एक मानक पुस्तकालय मॉड्यूल है। उदाहरण के लिए गणित या os.path जो os_path में बदल जाती है।

यह वैश्विक मॉड्यूल आयात करने के लिए नियम से अधिक तेजी से काम करता है, क्योंकि यह कैश्ड सूची पर मॉड्यूल की उपस्थिति के लिए जांच करता है। पायथन के प्रत्येक संस्करण की सूची यहाँ से आती है: github.com/jackmaney/python-stdlib-list

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_stdlib"}] # } import smart_imports smart_imports.all() print(math.pi)

नियम 6: उपसर्ग द्वारा आयात

अपने उपसर्ग के साथ जुड़े पैकेज से नाम से एक मॉड्यूल का आयात करता है। जब आप पूरे कोड में कई पैकेजों का उपयोग करते हैं तो इसका उपयोग करना सुविधाजनक होता है। उदाहरण के लिए, utils_ पैकेज मॉड्यूल को utils_ उपसर्ग के साथ एक्सेस किया जा सकता है।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_prefix", # "prefixes": [{"prefix": "utils_", "module": "my_package.utils"}]}] # } # #    : # # my_package # |-- __init__.py # |-- utils # |-- |-- __init__ # |-- |-- a.py # |-- |-- b.py # |-- subpackage # |-- |-- __init__ # |-- |-- c.py # c.py import smart_imports smart_imports.all() print(utils_a) print(utils_b)

नियम 7: मूल पैकेज से मॉड्यूल

यदि आपके पास प्रोजेक्ट के विभिन्न हिस्सों (उदाहरण के लिए, tests या migrations ) में एक ही नाम के उप-पैकेज हैं, तो आप उन्हें मूल पैकेज में नाम से आयात करने के लिए मॉड्यूल की खोज करने की अनुमति दे सकते हैं।

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_local_modules_from_parent", # "suffixes": [".tests"]}] # } # #    : # # my_package # |-- __init__.py # |-- a.py # |-- tests # |-- |-- __init__ # |-- |-- b.py # b.py import smart_imports smart_imports.all() print(a)

नियम 8: दूसरे पैकेज से बांधना

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

उदाहरण

 # : # { # "rules": [{"type": "rule_predefined_names"}, # {"type": "rule_local_modules_from_namespace", # "map": {"my_package.subpackage_1": ["my_package.subpackage_2"]}}] # } # #    : # # my_package # |-- __init__.py # |-- subpackage_1 # |-- |-- __init__ # |-- |-- a.py # |-- subpackage_2 # |-- |-- __init__ # |-- |-- b.py # a.py import smart_imports smart_imports.all() print(b)

अपने नियम जोड़ना

अपना नियम जोड़ना बहुत सरल है:

हमें वर्ग से प्राप्त होता है smart_imports.rules.BaseRule ।
हमें आवश्यक तर्क का एहसास है।
Smart_imports.rules.register विधि का उपयोग करके एक नियम पंजीकृत करें
नियम को कॉन्फ़िगर में जोड़ें।
???
लाभ।

एक उदाहरण वर्तमान नियमों के कार्यान्वयन में पाया जा सकता है।

लाभ

प्रत्येक स्रोत की शुरुआत में आयात की बहुस्तरीय सूची गायब हो गई है।

पंक्तियों की संख्या कम हो गई है। इससे पहले कि ब्राउज़र स्मार्ट आयात में बदल जाए, इसमें 6688 लाइनें थीं जो आयात के लिए जिम्मेदार थीं। संक्रमण के बाद, 2084 बनी रही (फ़ाइल और 130 आयातों के अनुसार स्मार्ट_इमपोर्ट्स की दो लाइनें, फ़ंक्शन और समान स्थानों से स्पष्ट रूप से कहा जाता है)।

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

विकास की योजनाएँ

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

स्मार्ट आयात के बारे में, मेरी योजना है:

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

इसके अलावा, मुझे लाइब्रेरी के डिफ़ॉल्ट व्यवहार और आयात नियमों के बारे में आपकी राय में दिलचस्पी है।

पाठ की इस शीट को ओवरपावर करने के लिए धन्यवाद :-D

पायथन आयात स्वचालन

यह सामान्य रूप से कैसे काम करता है?

डिफ़ॉल्ट आयात नियम

उत्पादकता

विन्यास

आयात नियम

नियम 1: पूर्वनिर्धारित नाम

नियम 2: स्थानीय मॉड्यूल

नियम 3: ग्लोबल मॉड्यूल

नियम 4: कस्टम नाम

नियम 5: मानक मॉड्यूल

नियम 6: उपसर्ग द्वारा आयात

नियम 7: मूल पैकेज से मॉड्यूल

नियम 8: दूसरे पैकेज से बांधना

अपने नियम जोड़ना

लाभ

विकास की योजनाएँ

More articles: