आरएआईआई: __del__ का क्या मतलब है?

Question

पहली नज़र में, ऐसा लगता है कि पाइथन की __del__ विशेष विधि सी ++ में विनाशक के समान फायदे प्रदान करती है। लेकिन पाइथन दस्तावेज के अनुसार (https://docs.python.org/3.4/reference/datamodel.html), कोई गारंटी है कि आपकी ऑब्जेक्ट की __del__ विधि कभी भी कॉल हो जाती है!

यह गारंटी नहीं है कि __del__() विधियों को ऑब्जेक्ट्स के लिए बुलाया जाता है जो दुभाषिया से बाहर निकलने पर मौजूद हैं।

तो दूसरे शब्दों में, विधि बेकार है! यही है ना एक हुक फ़ंक्शन जो वास्तव में बुलाया जा सकता है या नहीं, वास्तव में बहुत अच्छा नहीं करता है, इसलिए __del__ RAII के संबंध में कुछ भी नहीं प्रदान करता है। अगर मेरे पास कुछ आवश्यक सफाई है, तो मुझे कुछ समय चलाने के लिए इसकी आवश्यकता नहीं है, ओह, जब कभी भी जीसी वास्तव में ऐसा लगता है, तो मुझे विश्वसनीय रूप से, निश्चित रूप से और 100% समय चलाने की आवश्यकता है।

मुझे पता है कि अजगर संदर्भ प्रबंधकों, जो दूर उस कार्य के लिए अधिक उपयोगी हैं प्रदान करता है, लेकिन क्यों __del__ पर चारों ओर रखा गया था? क्या बात है?

Answer 1

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

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

जिस बिंदु पर आप तनाव डालते हैं क्योंकि दुभाषिया उन कारणों से बाहर निकल सकता है जो इसे क्लीनअप करने के लिए रोकते हैं (उदा। यह segfaults, या कुछ सी मॉड्यूल अस्थायी रूप से बाहर निकलें())।

सुरक्षित ऑब्जेक्ट अंतिमकरण के लिए पीईपी 442 है जिसे 3.4 में अंतिम रूप दिया गया है। मेरा सुझाव है कि आप इसे देखें।

https://www.python.org/dev/peps/pep-0442/

Answer 2

__del__ एक finalizer है। यह एक विनाशक नहीं है। फाइनल और विनाशक पूरी तरह से अलग जानवर हैं।

विनाशकों को भरोसेमंद कहा जाता है, और केवल निर्धारिती स्मृति प्रबंधन (जैसे सी ++) वाले भाषाओं में मौजूद हैं। पायथन के संदर्भ प्रबंधक (with कथन) कुछ परिस्थितियों में समान प्रभाव प्राप्त कर सकते हैं। ये भरोसेमंद हैं क्योंकि किसी वस्तु का जीवन निश्चित रूप से तय किया जाता है; सी ++ में, वस्तुएं मर जाती हैं जब वे स्पष्ट रूप से delete डी या जब कुछ गुंजाइश निकलती है (या जब एक स्मार्ट सूचक अपने विनाश के जवाब में उन्हें हटा देता है)। और वह तब होता है जब विनाशक दौड़ते हैं।

अंतिमकर्ता विश्वसनीय रूप से नहीं कहा जाता है। फाइनलाइज़र का एकमात्र वैध उपयोग an emergency safety net (एनबी: यह आलेख एक .NET परिप्रेक्ष्य से लिखा गया है, लेकिन अवधारणाएं उचित रूप से अच्छी तरह से अनुवाद करती हैं)। उदाहरण के लिए, open() द्वारा लौटाई गई फ़ाइल ऑब्जेक्ट्स स्वचालित रूप से अंतिम रूप से बंद हो जाती हैं। लेकिन आप अभी भी उन्हें बंद करना चाहते हैं (उदाहरण के लिए with कथन का उपयोग करना)। ऐसा इसलिए है क्योंकि वस्तुओं को कचरा कलेक्टर द्वारा गतिशील रूप से नष्ट कर दिया जाता है, जो तुरंत चला सकता है या नहीं, और पीढ़ी के कचरे के संग्रह के साथ, यह किसी दिए गए पास में कुछ वस्तुओं को इकट्ठा या नहीं कर सकता है।चूंकि कोई भी नहीं जानता कि भविष्य में हम किस तरह के अनुकूलन का आविष्कार कर सकते हैं, यह मानना ​​सबसे सुरक्षित है कि आप यह नहीं जान सकते कि कचरा कलेक्टर आपकी वस्तुओं को इकट्ठा करने के लिए कब मिल जाएगा। इसका मतलब है कि आप अंतिम रूपकों पर भरोसा नहीं कर सकते हैं।

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