जावा जैसी भाषाएं पदानुक्रमित पैकेज नामों का उपयोग क्यों करती हैं, जबकि पायथन नहीं करता है?

Question

मैंने जावा में एंटरप्राइज़ काम नहीं किया है, लेकिन मुझे अक्सर reverse-domain-name package naming convention दिखाई देता है। उदाहरण के लिए, एक स्टैक ओवरफ़्लो जावा पैकेज के लिए आप पैकेज com.stackoverflow के नीचे अपना कोड डाल देंगे।

मैं सिर्फ एक पायथन पैकेज में चला गया जो जावा-जैसे सम्मेलन का उपयोग करता है, और मुझे यकीन नहीं था कि इसके लिए और उसके खिलाफ तर्क क्या हैं, या वे जावा के समान ही पाइथन पर लागू होते हैं या नहीं। आप एक दूसरे से क्या पसंद करेंगे? क्या उन कारणों से भाषाएं लागू होती हैं?

Answer 1

यदि गिडो ने स्वयं घोषणा की कि रिवर्स डोमेन सम्मेलन का पालन किया जाना चाहिए, तो इसे अपनाया नहीं जाएगा, जब तक कि पाइथन में import के कार्यान्वयन में महत्वपूर्ण बदलाव न हों।

विचार करें: पायथन एक असफल-एल्गोरिदम के साथ रन-टाइम पर एक आयात पथ की खोज करता है; जावा संकलन-समय और रन-टाइम दोनों में एक संपूर्ण एल्गोरिदम के साथ पथ खोजता है। आगे बढ़ो, इस तरह से अपनी निर्देशिका की व्यवस्था का प्रयास करें:

folder_on_path/ 
    com/ 
     __init__.py 
     domain1/ 
      module.py 
      __init__.py 


other_folder_on_path/ 
    com/ 
     __init__.py 
     domain2/ 
      module.py 
      __init__.py 

फिर प्रयास करें:

from com.domain1 import module 
from com.domain2 import module 

वास्तव में उन बयानों में से एक सफल होगा। क्यूं कर? क्योंकि folder_on_path या other_folder_on_path खोज पथ पर अधिक आता है। जब पायथन from com. देखता है तो यह पहले com पैकेज को पकड़ सकता है। यदि इसमें domain1 शामिल होता है, तो पहले import सफल होंगे; यदि नहीं, तो यह ImportError फेंकता है और छोड़ देता है। क्यूं कर? क्योंकि import रनटाइम पर होना चाहिए, संभावित रूप से कोड के प्रवाह में किसी भी बिंदु पर (हालांकि अक्सर शुरुआत में)। कोई भी उस बिंदु पर एक विस्तृत पेड़-चलना चाहता है ताकि यह सत्यापित किया जा सके कि कोई संभावित मिलान नहीं है। यह मानता है कि अगर इसे com नामक एक पैकेज मिल जाता है, तो यह com पैकेज है।

इसके अलावा, अजगर निम्नलिखित बयानों बीच भेद नहीं करता:

from com import domain1 
from com.domain1 import module 
from com.domain1.module import variable 

सत्यापित करते हुए com है com प्रत्येक मामले में अलग होने जा रहा है की अवधारणा। जावा में, आपको वास्तव में केवल दूसरे मामले से निपटना होगा, और यह फ़ाइल सिस्टम के माध्यम से चलकर पूरा किया जा सकता है (मुझे लगता है कि नामकरण कक्षाओं का एक फायदा और फाइलें समान हैं)। पायथन में, यदि आपने फ़ाइल सिस्टम सहायता के अलावा कुछ भी आयात करने की कोशिश की है, तो पहला मामला पारदर्शी रूप से (init .py नहीं चलाया जा सकता है), दूसरा मामला पूरा हो सकता है, लेकिन आप हार जाएंगे module.py का प्रारंभिक चल रहा है, लेकिन तीसरा मामला पूरी तरह से अटूट है। कोड उपलब्ध होने के लिए variable के लिए निष्पादित करना होगा। और यह एक और मुख्य बिंदु है: import संकल्प नामस्थान से अधिक करता है, यह कोड निष्पादित करता है।

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

Answer 2

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

Answer 3

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

डोमेन नाम को उलटकर यह इसे एक पदानुक्रमित संरचना भी देता है, जो आसान है। तो आप अंत में उप-पैकेज हो सकते हैं।

केवल नकारात्मक पक्ष नाम की लंबाई है, लेकिन मेरे लिए यह बिल्कुल नकारात्मक नहीं है। मुझे लगता है कि यह किसी भी भाषा के लिए एक बहुत अच्छा विचार है जो इसका समर्थन करेगा।

उदाहरण के लिए जावास्क्रिप्ट पुस्तकालय ऐसा क्यों नहीं करते हैं? उनका वैश्विक नामस्थान एक बड़ी समस्या है, फिर भी जावास्क्रिप्ट पुस्तकालयों में 'ग्लोबल' जैसे सरल वैश्विक पहचानकर्ताओं का उपयोग किया जाता है जो अन्य जावास्क्रिप्ट पुस्तकालयों के साथ संघर्ष करते हैं।

Answer 4

जावा ऐसा करने में सक्षम है, क्योंकि यह एक अनुशंसित जावा मानक अभ्यास है, और जावा समुदाय द्वारा बहुत अधिक सार्वभौमिक रूप से स्वीकार किया जाता है। पाइथन इस सम्मेलन में नहीं है।

Answer 5

"अन्य कारणों से आप एक को प्राथमिकता क्यों दे सकते हैं?"

पायथन की शैली सरल है। जावा की शैली विभिन्न संगठनों से समान नाम उत्पादों की अनुमति देती है।

"क्या उन कारणों से भाषाएं लागू होती हैं?"

हां। आप "कॉम", "ऑर्ग", "मिल", "नेट", "edu" और "gov" नामक शीर्ष स्तर के पायथन पैकेज आसानी से प्राप्त कर सकते हैं और इन्हें अपने पैकेज को उप-पैकेज के रूप में रख सकते हैं।

संपादित। जब आप ऐसा करते हैं तो आपके पास कुछ जटिलता होती है, क्योंकि सभी को इन शीर्ष-स्तरीय पैकेजों को अपने क्रूर के साथ सहयोग और प्रदूषित नहीं करना पड़ता है।

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

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

जावा लोगों ने नाम टकराव से बचने के लिए अजीब ऑफ-द-दीवार अद्वितीय नाम चुनने वाले ओपन सोर्स समुदाय को पूर्ववत नहीं किया। जो लोग एक एक्सएमएल पार्सर लिखते हैं, दिलचस्प रूप से, इसे "पार्सर" नहीं कहते हैं। वे इसे "सैक्सन" या "ज़लान" या पूरी तरह से अजीब कुछ कहते हैं।

Answer 6

पायथन है, यह सिर्फ एक बहुत ही चतुर पदानुक्रम है। उदाहरण के लिए, os.path पर देखें। और पुस्तकालय डिजाइनरों को बहुत गहरा बनाने के लिए कुछ भी नहीं रोक रहा है, उदा। Django।

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

• सरल जटिल की तुलना में बेहतर है: वहाँ है कि इस के लिए तर्क को संबोधित की 'अजगर की जेन' कई हिस्से हैं।
• फ्लैट नेस्टेड से बेहतर है।
• सुंदर बदसूरत से बेहतर है। (जावा प्रणाली मेरे लिए बदसूरत लग रहा है।)

दूसरी ओर, वहाँ:

• नेमस्पेस एक महान विचार आवाज कर रहे हैं - के उन लोगों में से अधिक करते हैं! जो "com" पैकेज है कि लगभग सब कुछ के किसी सबपैकेज से मौजूद होता है -

Answer 7

अजगर क्योंकि आप एक समस्या के साथ खत्म हो ऐसा नहीं करती है? पैकेज विरासत स्थापित करने के पाइथन की विधि (फाइल सिस्टम विरासत के माध्यम से) इस सम्मेलन के साथ बिल्कुल अच्छी तरह से खेल नहीं है। जावा इसके साथ दूर हो सकता है क्योंकि पैकेज हेरार्की को 'पैकेज' कथन में खिलाए गए स्ट्रिंग अक्षर की संरचना द्वारा परिभाषित किया गया है, इसलिए कहीं भी एक स्पष्ट "कॉम" पैकेज होने की आवश्यकता नहीं है।

यदि आप सार्वजनिक रूप से पैकेज जारी करना चाहते हैं तो क्या करना है, लेकिन उस डोमेन नाम का स्वामित्व नहीं है जो पैकेज नाम में बोडिंग के लिए उपयुक्त है, या यदि आप अपने डोमेन नाम को बदलना (या खोना) समाप्त करना चाहते हैं किसी कारण के लिए। (बाद में अपडेट्स को एक अलग पैकेज नाम की आवश्यकता है? आप कैसे जानते हैं कि com.nifty_consultants.nifty_utility com.joe_blow_software.nifty_utility का एक नया संस्करण है? या, इसके विपरीत, आप कैसे जानते हैं कि यह एक नया संस्करण नहीं है? यदि आप अपने डोमेन नवीनीकरण को याद करें और नाम किसी डोमेन कैंपर द्वारा छीन लिया जाता है, और कोई और उनसे नाम खरीदता है, और वे सार्वजनिक रूप से सॉफ़्टवेयर पैकेज जारी करना चाहते हैं, तो क्या वे उसी नाम का उपयोग कर सकते हैं जिसका आपने पहले से उपयोग किया था?)

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

जीबी की टिप्पणी के जवाब में, मेरे बिंदु को और स्पष्ट करने के लिए: पायथन में, एक पैकेज एक निर्देशिका है जिसमें __init__.py फ़ाइल (और संभवतः एक या अधिक मॉड्यूल फ़ाइलें) शामिल हैं। एक पैकेज पदानुक्रम की आवश्यकता है कि प्रत्येक उच्च स्तरीय पैकेज एक पूर्ण, वैध पैकेज हो। यदि दो पैकेज (विशेष रूप से विभिन्न विक्रेताओं से, लेकिन एक ही विक्रेता से सीधे-संबंधित-संबंधित पैकेज भी नहीं) एक शीर्ष-स्तरीय पैकेज नाम साझा करते हैं, चाहे वह नाम 'कॉम' या 'वेब' या 'यूटिल' या जो भी हो, प्रत्येक उस शीर्ष-स्तरीय पैकेज के लिए __init__.py प्रदान करना होगा। हमें यह भी मानना ​​चाहिए कि ये संकुल निर्देशिका पेड़, यानी साइट-पैकेज/[pkg]/[subpkg] में एक ही स्थान पर स्थापित होने की संभावना है। इस प्रकार फाइल सिस्टम इस बात को लागू करता है कि केवल एक[pkg]/__init__.py है - तो कौन सा जीतता है? उस प्रश्न के सामान्य मामले के सही उत्तर (और नहीं हो सकते हैं) नहीं है। न ही हम दोनों फाइलों को एक साथ विलय कर सकते हैं।चूंकि हम नहीं जानते कि __init__.py में किसी अन्य पैकेज को क्या करने की आवश्यकता हो सकती है, शीर्ष-स्तरीय पैकेज साझा करने वाले उप-पैकेजों को तब तक काम नहीं माना जा सकता है जब तक कि दोनों स्थापित नहीं होते हैं, जब तक कि वे विशेष रूप से एक-दूसरे के साथ संगत होने के लिए लिखे गए हों (कम से कम इस में फ़ाइल)। यह एक वितरण दुःस्वप्न होगा और घोंसले के पैकेज के पूरे बिंदु को काफी अमान्य कर देगा। यह रिवर्स-डोमेन-नाम पैकेज पदानुक्रमों के लिए विशिष्ट नहीं है, हालांकि वे सबसे स्पष्ट खराब उदाहरण प्रदान करते हैं और (आईएमओ) दार्शनिक रूप से संदिग्ध हैं - यह वास्तव में दार्शनिक प्रश्नों के बजाय साझा शीर्ष-स्तरीय पैकेजों का व्यावहारिक मुद्दा है, जो कि हैं यहां मेरी मुख्य चिंता है।

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

Answer 8

सॉफ़्टवेयर पर जोएल पर कहीं भी, जोएल की कंपनी को बढ़ाने के दो तरीकों के बीच तुलना है: बेन & जैरी की विधि, जो छोटे से शुरू होती है और व्यवस्थित रूप से बढ़ती है, और अमेज़ॅन विधि पूरी तरह से धन जुटाने और बहुत व्यापक रूप से स्टैक करने की विधि शुरुआत से दावा।

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

ठीक है, यह सूर्य की अपेक्षा के अनुसार बिल्कुल नहीं निकला, लेकिन उन्होंने योजना बनाई कि वे सफल होंगे। निजी तौर पर, मैं उन परियोजनाओं को तुच्छ जानता हूं जो सफलता से कमजोर हो सकते हैं।

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

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