पायथन में संग्रह समान रूप से क्यों नहीं संभाले जाते हैं?

Question

सेट्स और सूचियों को पाइथन में अलग-अलग संभाला जाता है, और दोनों के साथ काम करने के लिए कोई समान तरीका नहीं लगता है। उदाहरण के लिए, set पर कोई आइटम जोड़कर add विधि का उपयोग करके किया जाता है, और list के लिए यह append विधि का उपयोग करके किया जाता है। मुझे पता है कि इसके पीछे विभिन्न अर्थशास्त्र हैं, लेकिन वहां सामान्य अर्थशास्त्र भी हैं, और अक्सर कुछ संग्रह के साथ काम करने वाला एल्गोरिदम अंतरों की तुलना में समानताओं के बारे में अधिक परवाह करता है। सी ++ एसटीएल दिखाता है कि यह काम कर सकता है, तो पाइथन में ऐसी कोई अवधारणा क्यों नहीं है?

संपादित करें: C++ में मैं एक (लगभग) संग्रह की मनमानी प्रकार, सूचियों और सेटों सहित में मान संग्रहीत करने के लिए एक output_iterator उपयोग कर सकते हैं। मैं एक एल्गोरिदम लिख सकता हूं जो इस तरह के इटरेटर को तर्क के रूप में लेता है और इसमें तत्व लिखता है। एल्गोरिदम तब कंटेनर (या अन्य डिवाइस, एक फ़ाइल हो सकता है) के लिए पूरी तरह से अज्ञेयवादी है जो इटेटरेटर का समर्थन करता है। यदि बैकिंग कंटेनर एक सेट है जो डुप्लिकेट को अनदेखा करता है, तो वह कॉलर का निर्णय होता है। मेरी विशिष्ट समस्या यह है कि अब यह कई बार हुआ है कि मैंने उदाहरण के लिए एक निश्चित कार्य के लिए list का उपयोग किया और बाद में फैसला किया कि set अधिक उपयुक्त है। अब मुझे अपने कोड में कई स्थानों पर appendadd को बदलना होगा। मैं बस सोच रहा हूं कि क्यों पाइथन के ऐसे मामलों के लिए कोई अवधारणा नहीं है।

Answer 1

प्रत्यक्ष उत्तर: यह एक डिज़ाइन दोष है।

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

विभिन्न प्रकार में इस कार्रवाई के लिए अलग-अलग नाम का उपयोग करते हुए एक नि: शुल्क भिन्नता होती है, और एक गरीब आधार मानक बनाया: पुस्तकालय उपयोगकर्ता कंटेनर बल्कि प्रत्येक बुनियादी कंटेनर के लिए काफी हद तक असंगत एपीआई प्रदान की तुलना में एक सुसंगत एपीआई का उपयोग करने, प्रोत्साहित करना चाहिए।

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

def foo(): 
    yield 1 
    yield 2 
    yield 3 

s = set(foo()) 
l = list(foo()) 
results1 = [i*2 for i in foo()] 
results2 = (i*2 for i in foo()) 
for r in foo(): 
    print r 

Answer 2

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

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

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

Answer 3

वास्तविक कारण शायद सिर्फ अजगर इतिहास से संबंधित है।

अंतर्निर्मित सेट प्रकार built-in until Python 2.6 नहीं था, और सेट मॉड्यूल पर आधारित था, जो कि Python 2.3 तक मानक लाइब्रेरी में नहीं था। स्पष्ट रूप से सेट प्रकार के अर्थशास्त्र को बदलना मूल सेट मॉड्यूल पर निर्भर मौजूदा कोड का एक मेजबान तोड़ सकता है, और आम तौर पर भाषा डिजाइनर बिना किसी बड़ी संख्या के रिलीज के मौजूदा कोड को तोड़ने से दूर रहते हैं।

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