अजगर की आंतरिक कक्षाओं का उद्देश्य क्या है?

Question

पायथन के आंतरिक / नेस्टेड वर्ग मुझे भ्रमित करते हैं। क्या ऐसा कुछ है जो उनके बिना पूरा नहीं किया जा सकता है? यदि हां, तो वह चीज क्या है?

Answer 1

Http://www.geekinterview.com/question_details/64739 से उद्धृत :

आंतरिक वर्ग के लाभ:

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

मुख्य लाभ संगठन है। भीतर की कक्षाओं के साथ जो कुछ भी पूरा किया जा सकता है, वह उनके बिना पूरा किया जा सकता है।

Comments

पाठ्यक्रम का एनकैप्सुलेशन तर्क पायथन पर लागू नहीं होता है।

— बोबिन्स

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

— क्रिस अरंड्ट

फिर भी, ये कारण हैं कि प्रोग्रामिंग में आंतरिक कक्षाओं का उपयोग किया जाता है। तुम बस एक प्रतिस्पर्धी जवाब नीचे शूट करने की कोशिश कर रहे हैं। यह जवाब इस दोस्त ने यहाँ दिया ठोस है।

— इन्वर्सस

@ इन्वर्टस: मैं असहमत हूं। यह एक उत्तर नहीं है, यह एक अलग भाषा (अर्थात् जावा) के बारे में किसी और के उत्तर से एक विस्तारित उद्धरण है । नीच और मुझे उम्मीद है कि दूसरे भी ऐसा ही करेंगे।

— केविन

मैं इस जवाब से सहमत हूं और आपत्तियों से असहमत हूं। जबकि नेस्टेड कक्षाएं नहीं हैं जावा के भीतर कक्षाएं, वे उपयोगी होते हैं। एक नेस्टेड वर्ग का उद्देश्य संगठन है। प्रभावी रूप से, आप एक वर्ग को दूसरे के नाम स्थान के नीचे रख रहे हैं। जब यह करने के लिए तार्किक समझ में आता है, तो यह पायथोनिक है: "नाम स्थान एक महान विचार का सम्मान कर रहे हैं - चलो उनमें से अधिक!" उदाहरण के लिए, एक DataLoaderवर्ग पर विचार करें जो एक CacheMissअपवाद को फेंक सकता है। मुख्य वर्ग के अंतर्गत अपवाद को रखने का DataLoader.CacheMissअर्थ है कि आप DataLoaderअभी आयात कर सकते हैं लेकिन फिर भी अपवाद का उपयोग कर सकते हैं।

— कोब्रिक

Answer 2

क्या ऐसा कुछ है जो उनके बिना पूरा नहीं किया जा सकता है?

नहीं। वे सामान्य रूप से शीर्ष स्तर पर कक्षा को परिभाषित करने के लिए बिल्कुल समकक्ष हैं, और फिर बाहरी वर्ग में इसके संदर्भ की नकल करते हैं।

मुझे नहीं लगता कि कोई विशेष कारण है कि नेस्टेड कक्षाएं 'अनुमति' हैं, इसके अलावा यह स्पष्ट रूप से उन्हें 'अस्वीकृत' करने के लिए कोई विशेष अर्थ नहीं देता है।

यदि आप एक ऐसी कक्षा की तलाश कर रहे हैं जो बाहरी / स्वामी ऑब्जेक्ट के जीवनचक्र के भीतर मौजूद है, और हमेशा बाहरी वर्ग की एक आवृत्ति का संदर्भ है - आंतरिक वर्ग जैसा कि जावा करता है - तो पायथन के नेस्टेड कक्षाएं वह चीज नहीं हैं। लेकिन आप कुछ हैक कर सकते हैं जैसे कि बात:

import weakref, new

class innerclass(object):
    """Descriptor for making inner classes.

    Adds a property 'owner' to the inner class, pointing to the outer
    owner instance.
    """

    # Use a weakref dict to memoise previous results so that
    # instance.Inner() always returns the same inner classobj.
    #
    def __init__(self, inner):
        self.inner= inner
        self.instances= weakref.WeakKeyDictionary()

    # Not thread-safe - consider adding a lock.
    #
    def __get__(self, instance, _):
        if instance is None:
            return self.inner
        if instance not in self.instances:
            self.instances[instance]= new.classobj(
                self.inner.__name__, (self.inner,), {'owner': instance}
            )
        return self.instances[instance]


# Using an inner class
#
class Outer(object):
    @innerclass
    class Inner(object):
        def __repr__(self):
            return '<%s.%s inner object of %r>' % (
                self.owner.__class__.__name__,
                self.__class__.__name__,
                self.owner
            )

>>> o1= Outer()
>>> o2= Outer()
>>> i1= o1.Inner()
>>> i1
<Outer.Inner inner object of <__main__.Outer object at 0x7fb2cd62de90>>
>>> isinstance(i1, Outer.Inner)
True
>>> isinstance(i1, o1.Inner)
True
>>> isinstance(i1, o2.Inner)
False

(यह क्लास डेकोरेटर का उपयोग करता है, जो पायथन 2.6 और 3.0 में नए हैं। अन्यथा आपको कक्षा की परिभाषा के बाद "इनर = इनरक्लास (आंतरिक)" कहना होगा।)

Comments

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

— इवगेनी सर्गेव

WeakKeyDictionaryइस उदाहरण में ए का उपयोग करने से वास्तव में कुंजियों को एकत्रित होने की अनुमति नहीं मिलती है, क्योंकि मान उनकी ownerविशेषता के माध्यम से संबंधित कुंजियों का दृढ़ता से संदर्भ देते हैं ।

— Kritzefitz

Answer 3

ऐसा कुछ है जिसे आपको समझने के लिए अपना सिर चारों ओर लपेटने की आवश्यकता है। अधिकांश भाषाओं में, कक्षा परिभाषाएँ संकलक के लिए निर्देश हैं। यही है, कार्यक्रम चलाने से पहले वर्ग बनाया जाता है। अजगर में, सभी कथन निष्पादन योग्य हैं। इसका मतलब है कि यह कथन:

class foo(object):
    pass

एक बयान है कि रनटाइम पर इस तरह से निष्पादित किया जाता है:

x = y + z

इसका मतलब यह है कि आप न केवल अन्य कक्षाओं के भीतर कक्षाएं बना सकते हैं, आप कहीं भी अपनी इच्छानुसार कक्षाएं बना सकते हैं। इस कोड पर विचार करें:

def foo():
    class bar(object):
        ...
    z = bar()

इस प्रकार, "आंतरिक वर्ग" का विचार वास्तव में भाषा का निर्माण नहीं है; यह एक प्रोग्रामर निर्माण है। गुइडो का एक बहुत अच्छा सारांश है कि यह यहाँ कैसे आया । लेकिन अनिवार्य रूप से, मूल विचार यह है कि यह भाषा के व्याकरण को सरल बनाता है।

Answer 4

कक्षाओं के भीतर घोंसले के शिकार वर्ग:

• नेस्टेड कक्षाएं वर्ग परिभाषा को धुंधला करती हैं जिससे यह देखने में मुश्किल होती है कि क्या चल रहा है।

• नेस्टेड वर्ग युग्मन बना सकते हैं जो परीक्षण को और अधिक कठिन बना देगा।

• पायथन में, आप जावा के विपरीत एक फ़ाइल / मॉड्यूल में एक से अधिक वर्ग रख सकते हैं, इसलिए वर्ग अभी भी शीर्ष स्तर की कक्षा के करीब है और यहां तक ​​कि वर्ग का नाम "_" के साथ उपसर्ग कर सकता है ताकि यह संकेत मिल सके कि दूसरों को नहीं होना चाहिए उसका इस्तेमाल कर रहे हैं।

जिस स्थान पर नेस्टेड कक्षाएं उपयोगी साबित हो सकती हैं, वह फ़ंक्शन के भीतर है

def some_func(a, b, c):
   class SomeClass(a):
      def some_method(self):
         return b
   SomeClass.__doc__ = c
   return SomeClass

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

Answer 5

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

Comments

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

— एक्यूमेनस

इसे लगाने का दूसरा तरीका: Nodeके नाम स्थान के तहत है DoublyLinkedList, और यह तार्किक समझदारी देता है। यह पायथोनिक है: "नेमस्पेस एक महान विचार का सम्मान करते हैं - चलो उनमें से अधिक करते हैं!"

— काबरिक

@ कर्बरीक: "उन लोगों में से अधिक" करना उन्हें घोंसले के शिकार के बारे में कुछ नहीं कहता है।

— एथन फुरमान

Answer 6

क्या ऐसा कुछ है जो उनके बिना पूरा नहीं किया जा सकता है? यदि हां, तो वह चीज क्या है?

ऐसा कुछ है जो आसानी से नहीं किया जा सकता है : संबंधित वर्गों की विरासत ।

यहाँ से संबंधित वर्गों के साथ एक minimalist उदाहरण है Aऔर B:

class A(object):
    class B(object):
        def __init__(self, parent):
            self.parent = parent

    def make_B(self):
        return self.B(self)


class AA(A):  # Inheritance
    class B(A.B):  # Inheritance, same class name
        pass

यह कोड एक बहुत ही उचित और अनुमानित व्यवहार की ओर ले जाता है:

>>> type(A().make_B())
<class '__main__.A.B'>
>>> type(A().make_B().parent)
<class '__main__.A'>
>>> type(AA().make_B())
<class '__main__.AA.B'>
>>> type(AA().make_B().parent)
<class '__main__.AA'>

यदि Bएक उच्च-स्तरीय वर्ग होता, तो आप self.B()विधि में नहीं लिख सकते थे, make_Bलेकिन बस लिखेंगे B(), और इस प्रकार पर्याप्त कक्षाओं के लिए गतिशील बंधन खो देंगे ।

ध्यान दें कि इस निर्माण में, आपको कभी भी कक्षा Aके शरीर में कक्षा का उल्लेख नहीं करना चाहिए B। यह parentवर्ग में विशेषता को पेश करने की प्रेरणा है B।

बेशक, इस गतिशील बंधन को कक्षाओं के थकाऊ और त्रुटि-प्रवण इंस्ट्रूमेंटेशन की कीमत पर आंतरिक वर्ग के बिना फिर से बनाया जा सकता है ।

Answer 7

मुख्य उपयोग का मामला जिसके लिए मैं इसका उपयोग करता हूं, वह है छोटे मॉड्यूल के प्रसार को रोकना और अलग मॉड्यूल की आवश्यकता नहीं होने पर नाम स्थान के प्रदूषण को रोकना। यदि मैं एक मौजूदा वर्ग का विस्तार कर रहा हूं, लेकिन उस मौजूदा वर्ग को एक और उपवर्ग का संदर्भ देना चाहिए जिसे हमेशा इसके साथ जोड़ा जाना चाहिए। उदाहरण के लिए, मेरे पास एक ऐसा utils.pyमॉड्यूल हो सकता है, जिसमें कई सहायक वर्ग होते हैं, जो कि आवश्यक रूप से एक साथ युग्मित नहीं होते हैं, लेकिन मैं उन सहायक वर्गों में से कुछ के लिए युग्मन को सुदृढ़ करना चाहता हूं । उदाहरण के लिए, जब मैं https://stackoverflow.com/a/8274307/2718295 लागू करता हूं

: utils.py:

import json, decimal

class Helper1(object):
    pass

class Helper2(object):
    pass

# Here is the notorious JSONEncoder extension to serialize Decimals to JSON floats
class DecimalJSONEncoder(json.JSONEncoder):

    class _repr_decimal(float): # Because float.__repr__ cannot be monkey patched
        def __init__(self, obj):
            self._obj = obj
        def __repr__(self):
            return '{:f}'.format(self._obj)

    def default(self, obj): # override JSONEncoder.default
        if isinstance(obj, decimal.Decimal):
            return self._repr_decimal(obj)
        # else
        super(self.__class__, self).default(obj)
        # could also have inherited from object and used return json.JSONEncoder.default(self, obj) 

तब हम कर सकते हैं:

>>> from utils import DecimalJSONEncoder
>>> import json, decimal
>>> json.dumps({'key1': decimal.Decimal('1.12345678901234'), 
... 'key2':'strKey2Value'}, cls=DecimalJSONEncoder)
{"key2": "key2_value", "key_1": 1.12345678901234}

बेशक, हम json.JSONEnocderपूरी तरह से विरासत में मिले और डिफ़ॉल्ट () को ओवरराइड कर सकते हैं :

:

import decimal, json

class Helper1(object):
    pass

def json_encoder_decimal(obj):
    class _repr_decimal(float):
        ...

    if isinstance(obj, decimal.Decimal):
        return _repr_decimal(obj)

    return json.JSONEncoder(obj)


>>> json.dumps({'key1': decimal.Decimal('1.12345678901234')}, default=json_decimal_encoder)
'{"key1": 1.12345678901234}'

लेकिन कभी-कभी सिर्फ कन्वेंशन के लिए, आप utilsएक्स्टेंसिबिलिटी के लिए कक्षाओं से बने रहना चाहते हैं ।

यहां एक और उपयोग-मामला है: मैं अपने ओउटरक्लास में म्युटेबल्स के लिए एक कारखाना चाहता हूं, जिसमें बिना किसी को आमंत्रित किए copy:

class OuterClass(object):

    class DTemplate(dict):
        def __init__(self):
            self.update({'key1': [1,2,3],
                'key2': {'subkey': [4,5,6]})


    def __init__(self):
        self.outerclass_dict = {
            'outerkey1': self.DTemplate(),
            'outerkey2': self.DTemplate()}



obj = OuterClass()
obj.outerclass_dict['outerkey1']['key2']['subkey'].append(4)
assert obj.outerclass_dict['outerkey2']['key2']['subkey'] == [4,5,6]

मैं इस पैटर्न को @staticmethodडेकोरेटर पर पसंद करता हूं जिसे आप अन्यथा एक फैक्ट्री फ़ंक्शन के लिए उपयोग करेंगे।

Answer 8

1. दो कार्यात्मक समान तरीके

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

तरीका 1: नेस्टेड क्लास परिभाषा
(= "नेस्टेड क्लास")

class MyOuter1:
    class Inner:
        def show(self, msg):
            print(msg)

तरीका 2: आउटर क्लास से जुड़ा मॉड्यूल स्तर इनर क्लास
(= "संदर्भित आंतरिक वर्ग")

class _InnerClass:
    def show(self, msg):
        print(msg)

class MyOuter2:
    Inner = _InnerClass

_{^{PEP8 का उपयोग करने के लिए अंडरस्कोर का उपयोग किया जाता है "आंतरिक इंटरफेस (पैकेज, मॉड्यूल, कक्षाएं, फ़ंक्शंस, विशेषताओं या अन्य नाम) - को एकल अग्रणी अंडरस्कोर के साथ उपसर्ग किया जाना चाहिए।"}}

2. समानता

नीचे दिए गए कोड स्निपेट "नेस्टेड क्लास" बनाम "संदर्भित आंतरिक वर्ग" के कार्यात्मक समानता को प्रदर्शित करता है; वे आंतरिक कक्षा उदाहरण के प्रकार के लिए कोड जाँच में उसी तरह का व्यवहार करेंगे। कहने की जरूरत नहीं है, के m.inner.anymethod()साथ m1और इसी तरह व्यवहार करेंगेm2

m1 = MyOuter1()
m2 = MyOuter2()

innercls1 = getattr(m1, 'Inner', None)
innercls2 = getattr(m2, 'Inner', None)

isinstance(innercls1(), MyOuter1.Inner)
# True

isinstance(innercls2(), MyOuter2.Inner)
# True

type(innercls1()) == mypackage.outer1.MyOuter1.Inner
# True (when part of mypackage)

type(innercls2()) == mypackage.outer2.MyOuter2.Inner
# True (when part of mypackage)

3. अंतर

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

3.1 कोड एनकैप्सुलेशन

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

जबकि कोई भी * एक का उपयोग नहीं कर रहा है from packagename import *, कोड पूरा होने / इंटैलिजेंस के साथ आईडीई का उपयोग करते समय कम मात्रा में मॉड्यूल स्तर चर उदाहरण के लिए अच्छा हो सकता है।

^{_{* सही है?}}

3.2 कोड की पठनीयता

Django प्रलेखन मॉडल मेटाडेटा के लिए आंतरिक वर्ग मेटा का उपयोग करने का निर्देश देता है । यह थोड़ा और अधिक स्पष्ट है * फ्रेमवर्क उपयोगकर्ताओं को class Foo(models.Model)आंतरिक के साथ लिखने के लिए निर्देश देना class Meta;

class Ox(models.Model):
    horn_length = models.IntegerField()

    class Meta:
        ordering = ["horn_length"]
        verbose_name_plural = "oxen"

इसके बजाय "एक लिखें class _Meta, फिर एक class Foo(models.Model)साथ लिखें Meta = _Meta";

class _Meta:
    ordering = ["horn_length"]
    verbose_name_plural = "oxen"

class Ox(models.Model):
    Meta = _Meta
    horn_length = models.IntegerField()

• "नेस्टेड क्लास" दृष्टिकोण के साथ कोड को एक नेस्टेड बुलेट पॉइंट सूची पढ़ी जा सकती है , लेकिन "संदर्भित आंतरिक वर्ग" विधि के साथ _Metaइसकी "चाइल्ड आइटम" (विशेषताओं) को देखने की परिभाषा देखने के लिए वापस स्क्रॉल करना होगा ।

• यदि आपके कोड नेस्टिंग स्तर बढ़ता है या किसी अन्य कारण से पंक्तियां लंबी होती हैं, तो "संदर्भित आंतरिक वर्ग" विधि अधिक पठनीय हो सकती है।

_{^{* बेशक, स्वाद की बात है}}

3.3 थोड़ा अलग त्रुटि संदेश

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

innercls1.foo()
# AttributeError: type object 'Inner' has no attribute 'foo'

innercls2.foo()
# AttributeError: type object '_InnerClass' has no attribute 'foo'

इसका कारण यह है कि typeआंतरिक वर्ग हैं

type(innercls1())
#mypackage.outer1.MyOuter1.Inner

type(innercls2())
#mypackage.outer2._InnerClass

Answer 9

मैंने def test_something():100% परीक्षण कवरेज (जैसे कुछ विधियों को ओवरराइड करके बहुत ही ट्रिगर किए गए लॉगिंग स्टेटमेंट का परीक्षण करना) के करीब पहुंचने के लिए जानबूझकर छोटी चीज़ों (यानी अंदर ) के भीतर जानबूझकर छोटी गाड़ी उपवर्ग बनाने के लिए पायथन की आंतरिक कक्षाओं का उपयोग किया है ।

पूर्वव्यापी में यह एड के उत्तर के समान है https://stackoverflow.com/a/722036/1101109

इस तरह के आंतरिक वर्गों को दायरे से बाहर जाना चाहिए और कचरा संग्रह के लिए तैयार होना चाहिए, क्योंकि सभी संदर्भों को हटा दिया गया है। उदाहरण के लिए, निम्न inner.pyफ़ाइल लें:

class A(object):
    pass

def scope():
    class Buggy(A):
        """Do tests or something"""
    assert isinstance(Buggy(), A)

मुझे OSX पायथन 2.7.6 के तहत निम्नलिखित उत्सुक परिणाम मिलते हैं:

>>> from inner import A, scope
>>> A.__subclasses__()
[]
>>> scope()
>>> A.__subclasses__()
[<class 'inner.Buggy'>]
>>> del A, scope
>>> from inner import A
>>> A.__subclasses__()
[<class 'inner.Buggy'>]
>>> del A
>>> import gc
>>> gc.collect()
0
>>> gc.collect()  # Yes I needed to call the gc twice, seems reproducible
3
>>> from inner import A
>>> A.__subclasses__()
[]

संकेत - मत जाओ और Django मॉडल के साथ ऐसा करने की कोशिश करो, जो मेरे छोटी कक्षाओं के संदर्भ में अन्य (कैश्ड?) रखने के लिए लग रहा था।

इसलिए सामान्य तौर पर, मैं इस तरह के उद्देश्य के लिए आंतरिक कक्षाओं का उपयोग करने की सिफारिश नहीं करूंगा जब तक कि आप वास्तव में उस मूल्य को 100% परीक्षण कवरेज नहीं करते हैं और अन्य तरीकों का उपयोग नहीं कर सकते हैं। हालाँकि मुझे लगता है कि यह जानकर अच्छा लगता है कि यदि आप इसका उपयोग करते हैं __subclasses__(), तो यह कभी-कभी आंतरिक कक्षाओं द्वारा प्रदूषित हो सकता है । किसी भी तरह से अगर आपने इसका अनुसरण किया है, तो मुझे लगता है कि हम इस बिंदु पर बहुत गहरे हैं, निजी डंडर्सकोर्स और सभी।

Comments

क्या यह सब उपवर्गों और आंतरिक वर्गों के बारे में नहीं है ?? ए

— कलस

उपरोक्त आवरण में बग्गी ए से विरासत में मिली है। इसके अलावा अंतर्निहित फ़ंक्शन issubclass ()

— klaas

थैंक्स @klaas, मुझे लगता है कि यह स्पष्ट किया जा सकता है कि मैं सिर्फ .__subclasses__()यह समझने के लिए उपयोग कर रहा हूं कि पायथन में चीजों के दायरे से बाहर जाने पर कचरा कलेक्टर के साथ कैसे बातचीत होती है। यह नेत्रहीन पद पर हावी होने लगता है इसलिए पहले 1-3 पैराग्राफ थोड़ा अधिक विस्तार के लायक हैं।

— pzrq