क्या आपके पास बहुत सारे आवेषण हो सकते हैं (पायथन में)?

Question

हाल ही में, मैं लगभग हर एक समारोह में asserts जोड़ रहा हूं जो मैं प्रत्येक इनपुट को सत्यापित करने के लिए करता हूं जैसे कि प्रकार की जांच के लिए एक गरीब व्यक्ति के प्रतिस्थापन के प्रकार या विकास के दौरान गलती से डेटा खराब करने से रोकने के लिए। उदाहरण के लिए,

def register_symbol(self, symbol, func, keypress=None): 
    assert(isinstance(symbol, basestring)) 
    assert(len(symbol) == 1) 
    assert(callable(func)) 
    assert(keypress is None or type(keypress) is int) 
    self.symbols_map[symbol] = (func, keypress) 
    return 

हालांकि, मुझे चिंता है कि इस बतख टाइपिंग के विचार के खिलाफ जाता है हूँ, और है कि मैं भी पानी में गिर जा रहे हैं या अपने आप को अनावश्यक रूप से बाधा। क्या आपके पास कभी भी बहुत अधिक कथन बयान हो सकते हैं? रोकने के लिए एक अच्छा समय कब है?

Answer 1

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

assert(callable(func)) 

इस तरह के एक ज़ोर के लिए एक उदाहरण हो सकता है - अगर func प्रतिदेय नहीं है, तुम कहाँ वास्तविक त्रुटि है से कोड की एक पूरी तरह से अलग लाइन पर एक त्रुटि संदेश मिलता है, और यह नहीं हो सकता है स्पष्ट रहें कि गैर-कॉल करने योग्य ऑब्जेक्ट self.symbols_map में कैसे समाप्त हुआ। मैं "शायद" लिख सकता हूं क्योंकि यह आपके शेष कोड पर निर्भर करता है - यदि यह एकमात्र ऐसा स्थान है जहां self.symbols_map अपडेट हो जाता है, तो दावा भी अनावश्यक हो सकता है।

पहला और आखिरी जोर निश्चित रूप से बतख-टाइपिंग, के विचार के खिलाफ है और दूसरा एक अनावश्यक है। यदि symbol लंबाई 1 की स्ट्रिंग नहीं है, तो संभावना है कि self.symbols_map[symbol] किसी भी तरह KeyError उठाएगा, इसलिए आवेषण की आवश्यकता नहीं है।

पिछले ज़ोर भी गलत है - type(keypress)None नहीं किया जा सकता है, और प्रकार की जाँच करता isinstance() से किया जाना चाहिए। बहुत विशिष्ट अनुप्रयोग हो सकते हैं जहां आप उपप्रकारों की अनुमति नहीं दे सकते हैं, लेकिन type(x) == int के बजाय चेक type(x) is int के साथ किया जाना चाहिए। None के लिए जांच x is None द्वारा की जानी चाहिए, type(x) is NoneType द्वारा नहीं।

आपको शायद यूनिट परीक्षणों का एक अच्छा सेट लिखना चाहिए - वे आवेषण से कहीं अधिक उपयोगी होंगे, और आपके लगभग सभी आवेषण अनावश्यक हो सकते हैं।

Answer 2

आपके कोड में आवेषण लगभग उतने ही उपयोगी नहीं हैं जितना unittests। उत्तरार्द्ध में से अधिक, पूर्व में से कम करें।

Answer 3

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