पायथन के "PEP-302 नए आयात हुक" का अनुभव [बंद]


40

मैं रूबी (CRuby) के डेवलपर्स में से एक हूं। हम रूबी 2.0 रिलीज (2012 / फरवरी को रिलीज करने की योजना) पर काम कर रहे हैं।

पायथन में "PEP302: नई आयात हुक" (2003) है:

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

हम PEP302 के समान एक विशेषता रूबी 2.0 (CRuby 2.0) में पेश करने पर विचार कर रहे हैं। मैं एक प्रस्ताव बनाना चाहता हूं, जो माटज को राजी कर सके। वर्तमान में, CRuby एक मानक तरीके से केवल फ़ाइल सिस्टम से स्क्रिप्ट लोड कर सकता है।

यदि आपके पास PEP 302 के बारे में कोई अनुभव या विचार है, तो कृपया साझा करें।

उदाहरण:

  1. यह एक महान कल्पना है। इसे बदलने की जरूरत नहीं है।
  2. यह लगभग अच्छा है, लेकिन यह इस समस्या है ...
  3. अगर मैं 2003 में वापस जा सकता था, तो मैं कल्पना को बदलूंगा ...

6
वाह, YARV आदमी खुद, नमस्ते और प्रोग्रामर में आपका स्वागत है! ;) स्टैक एक्सचेंज पर हम वास्तव में खुली हुई चर्चा पसंद नहीं करते हैं, हम इसके बजाय विशिष्ट समस्याओं को हल करना पसंद करते हैं (हमारे FAQ को त्वरित रूप से पढ़ें ) - जो मुझे अनुमान है कि आपका सवाल स्टैक ओवरफ्लो पर क्यों बंद हुआ था और यह पहले से ही है यहाँ बंद वोट आपको इसे थोड़ा और विशिष्ट बनाने पर ध्यान देना चाहिए - क्या आपको PEP 302 के बारे में विशिष्ट चिंता है जिसने इस प्रश्न को प्रेरित किया है?
यानि

4
आपकी टिप्पणी के लिए धन्यवाद, यानिस। मुझे लगता है कि मैं "सॉफ्टवेयर आर्किटेक्चर" के बारे में चर्चा करना चाहता हूं। PEP302 अजगर इंटरप्रेटर पर अपने स्वयं के लोडर का विस्तार करने के लिए शक्तिशाली और सामान्य ढांचा लगता है। हालांकि, शक्तिशाली विशेषता में जोखिम होता है जैसे कि अति प्रयोग (जादुई कोड उत्पन्न करता है), दुभाषिया के अनुकूलन को रोकना। इसलिए मैं जानना चाहता हूं कि यह विस्तार ढांचा मीठा है या अजगर उपयोगकर्ताओं और दुभाषिया डेवलपर्स के लिए नहीं है। मेरा मानना ​​है कि इतिहास का अध्ययन रूबी 2.0 पर अच्छा अनुमान लगाने में मेरी मदद करेगा।
कोच्चि सासदा

शुक्रिया मेरे प्रश्न को बहुत संशोधित करने का। और मुझे खेद है कि अगर यह सवाल बेहतर नहीं है।
कोच्चि सासदा

यह एक शानदार उदाहरण है कि कैसे एक प्रश्न जो सतह पर दिखाई देता है, हमारे "ओपिनियन पोल" परीक्षण को विफल करने के लिए, फिर भी आश्चर्यजनक मूल्य साबित हो सकता है।
रॉस पैटरसन

जवाबों:


47

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

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

PEP 420 (पायथन 3.3 के लिए कार्यान्वित) प्रोटोकॉल में कुछ जोड़ देता है जिससे आयातकों को नाम स्थान पैकेज में अंशदान करने की अनुमति मिलती है। यह फाइंडर एपीआई परिभाषा में एक नामकरण समस्या को भी ठीक करता है (प्रभावी रूप से गलत "find_module" के साथ गलत नाम "find_module" की जगह)। यह उम्मीद है कि सभी को भाषा में विशेष रूप से कुछ ही हफ्तों में 3.3rc1 रोल के आसपास के समय में स्पष्ट रूप से प्रलेखित किया जाना चाहिए।

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

पीईपी 406 (http://www.python.org/dev/peps/pep-0406/) बेहतर स्थिति एनकैप्सुलेशन के साथ पायथन के दृष्टिकोण के संभावित पीछे की ओर विकास पर चर्चा करता है। यदि आपके पास शुरू से ही एक समझाया राज्य मॉडल है, तो आप अपने एपीआई को तदनुसार परिभाषित कर सकते हैं और आयातकों और लोडरों को वैश्विक स्थिति तक पहुंचने से बचा सकते हैं (इसके बजाय सक्रिय इंजन का संदर्भ दिया जा रहा है)।

PEP 302 में एक और लापता टुकड़ा उस आयातक द्वारा प्रदान किए गए मॉड्यूल पर एक पुनरावृत्ति के लिए एक आयातक से पूछने की क्षमता है (यह फ्रीज उपयोगिताओं और स्वचालित दस्तावेज़ उपयोगिताओं जैसी चीजों के लिए आवश्यक है जो डॉक्ट्रिंग निकालते हैं)। चूंकि यह अविश्वसनीय रूप से उपयोगी है, आप शायद इसे प्राप्त करने से बेहतर मानकीकरण करेंगे: http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules (हम शायद इसे औपचारिक रूप से निर्दिष्ट करने के लिए ऊपर उठाएंगे पायथन 3.4 में एपीआई)

और मेरी अंतिम टिप्पणी यह ​​है कि आपको आयात प्रणाली और लोडर ऑब्जेक्ट्स के बीच जिम्मेदारी के विभाजन पर बारीकी से विचार करना चाहिए। विशेष रूप से, "load_module" API को अलग से "init_module" और "exec_module" चरणों में विभाजित करने पर विचार करें। इससे आपको उस डिग्री को कम करने की अनुमति मिल सकती है, जिसके लिए लोडरों को आयात राज्य के साथ सीधे बातचीत करने की आवश्यकता होती है।

PEP 302 और importlib एक अधिक लचीली आयात प्रणाली के लिए एक शानदार शुरुआती बिंदु हैं, लेकिन निश्चित रूप से गलतियां हैं जो हमने बनाई हैं जो कि टालने लायक हैं।


1
वे अभी तक पूरी तरह से समाप्त नहीं हुए हैं, लेकिन पूर्ण आयात प्रणाली डॉक्स का एक प्रारंभिक मसौदा docs.python.org/dev/reference/import
ncoghlan

1
python.org/dev/peps/pep-0451 Python 3.4 के लिए पायथन की आयात प्रणाली का एक अपडेट है जो ब्रेट और यहां से कई टिप्पणियों को संबोधित करता है।
ncoghlan

28

Ncoghlan के बगल में मैं पायथन की आयात प्रणाली का दूसरा अनुरक्षक हूं और इसके वर्तमान कार्यान्वयन के लेखक, importlib (http://docs.python.org/dev/py3k/library/importlib.html) हूं। सब कुछ निक ने कहा कि मैं इससे सहमत हूं, इसलिए मैं केवल कुछ अतिरिक्त जानकारी जोड़ना चाहता हूं।

सबसे पहले, PEP 302 पर सीधे निर्भर न रहें, बल्कि यह देखें कि एब्सट्रैक्ट बेस क्लासेस आदि के मामले में importlib क्या प्रदान करता है। बैकवर्ड-कम्पैटिबिलिटी के लिए पीईपी 302 के साथ संगत होना चाहिए, लेकिन मुझे अपने कुछ को जोड़ना था असली लचीलेपन के लिए समर्थन को समाप्त करने के लिए स्वयं के एपीआई।

एक और महत्वपूर्ण बिंदु यह है कि आप डेवलपर्स को लचीलेपन के दो टुकड़े दे रहे हैं। एक फाइल सिस्टम पर सीधे व्यक्तिगत फ़ाइलों के रूप में (मैं इसे स्टोरेज बैक-एंड इंपोर्ट के रूप में कहता हूं ) के अलावा एक तरह से कोड स्टोर करने की क्षमता है , उदाहरण के लिए यह कोड को ज़िप फाइल, साइक्लाइट डेटाबेस, आदि में रहने की अनुमति देता है। । दूसरा समर्थन किसी तरह से प्री-या पोस्ट-प्रोसेस कोड को नियंत्रित करने की अनुमति देने में है, जैसे कि Quixote (https://www.mems-exchange.org/software/quixote/) और स्ट्रिंग लिटरल्स का इसका वैकल्पिक उपयोग जिसे असाइन नहीं किया गया है एक चर समर्थन करने के लिए बहुत आसान होगा।

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

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

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


-1

PEP 302 आपको पायथन आयात तंत्र में हुक करने की अनुमति देता है, जिसका अर्थ है कि आप डेटाबेस, ज़िप फ़ाइलों और जैसे अन्य स्रोतों से कोड आयात कर सकते हैं।

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

मुझे कोने के मामलों के बारे में लंबे और कठिन सोचने की सलाह देनी चाहिए। तब आपको एक उपयोगी कार्यान्वयन प्राप्त होने की संभावना है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.