पायथन में किसी अन्य, तृतीय-पक्ष मॉड्यूल से क्लास विधि को फिर से परिभाषित करना कितना बुरा है?किसी तृतीय-पक्ष मॉड्यूल से किसी विधि को ओवरराइड करना कितना बुरा है?
वास्तव में, उपयोगकर्ता न्यूमपी मैट्रिस बना सकते हैं जिनमें numbers with uncertainty शामिल है; आदर्श रूप में, मैं उनके कोड को अनमोडिफाइड चलाने के लिए चाहूंगा (जब कोड फ़्लोट मैट्रिस का उपयोग करता है); विशेष रूप से, यह बहुत अच्छा होगा अगर मैट्रिक्स m
के विपरीत m.I
के साथ प्राप्त किया जा सकता है, इस तथ्य के बावजूद कि m.I
को अपने कोड के साथ गणना की जानी है (मूल I
विधि सामान्य रूप से काम नहीं करती है)।
numpy.matrix.I को फिर से परिभाषित करना कितना बुरा है? एक बात के लिए, यह तीसरे पक्ष के कोड के साथ छेड़छाड़ करता है, जिसे मैं पसंद नहीं करता, क्योंकि यह मजबूत नहीं हो सकता है (क्या होगा अगर अन्य मॉड्यूल समान हों? ...)। एक और समस्या यह है कि नया numpy.matrix.I एक रैपर है जिसमें एक छोटा ओवरहेड शामिल होता है जब मूल numpy.matrix.I वास्तव में व्यस्त मैट्रिक्स प्राप्त करने के लिए लागू किया जा सकता है।
NumPy matrices subclassing है और केवल I
विधि को बेहतर ढंग से बदल रहा है? इससे उपयोगकर्ता अपने कोड को अपडेट कर सकते हैं और m = matrix_with_uncert(…)
(numpy.matrix(…)
का उपयोग करते हुए अनिश्चितता के साथ संख्याओं के मैट्रिक्स बना सकते हैं, फ्लोट्स के मैट्रिक्स के लिए), लेकिन शायद यह एक असुविधा है जिसे मजबूती के लिए स्वीकार किया जाना चाहिए? मैट्रिक्स इनवर्जन अभी भी m.I
के साथ किया जा सकता है, जो अच्छा है ... दूसरी तरफ, यह अच्छा होगा अगर उपयोगकर्ता डेटा प्रकारों की जांच को परेशान किए बिना सीधे numpy.matrix()
के साथ अपने सभी मैट्रिस (फ्लोट या अनिश्चितताओं के साथ संख्याओं) का निर्माण कर सकें ।
कोई टिप्पणी, या अतिरिक्त दृष्टिकोण का स्वागत किया जाएगा!
बंदर पैचिंग और इसकी संभावित समस्याओं के इस स्पष्ट वर्णन के लिए धन्यवाद! मुझे कहना होगा कि NumPy उन्हें समर्थन करके "कुछ के सरणी" की परिभाषा को प्रोत्साहित करता है ('numpy.array ([any_object])')। तो, मैं कहूंगा कि "किसी भी प्रकार की वस्तु के matrices" एक अवधारणा है जो NumPy-element-wise अतिरिक्त द्वारा समर्थित है स्वचालित रूप से समर्थित है आदि। उसने कहा, मैं पूरी तरह से आपकी प्रतिक्रिया की सदस्यता लेता हूं! – EOL