2012-09-19 12 views
5

में * तर्कों के उपयोग के ऊपर उचित उपयोग बनाम मैं एक ओपन सोर्स पैकेज के लिए स्रोत कोड देख रहा हूं जिसका मैं उपयोग कर रहा हूं। लगभग हर समारोह नामित तर्कों के बजाय * तर्क का उपयोग करता है। मुझे कोड का पालन करना और कोड का उपयोग करना मुश्किल लगता है, क्योंकि हर बार जब मैं एक फ़ंक्शन कॉल करना चाहता हूं तो मुझे वापस जाना होगा, स्रोत कोड चुनें, और पहचानें कि तर्क क्या होना चाहिए, और वे किस क्रम में होना चाहिए। मेरे पास यह सवाल है: क्या हर समारोह में * तर्कों का उपयोग करने के लिए एक अनिवार्य कारण है, या क्या यह अवधारणा का दुरुपयोग है? धन्यवाद, बीपाइथन

+0

यदि कोई तर्क है, तो वहां एक (सटीक!) डॉकस्ट्रिंग होना आवश्यक है। – James

+0

यह क्या पैकेज है? दोष खेल नहीं खेलना है, लेकिन उनके पास वैध कारण हो सकता है। –

उत्तर

4

यह एक व्यक्तिगत तर्क हो सकता है, लेकिन मैं केवल * args और ** kwargs का उपयोग जब मैं वैकल्पिक फ़ील्ड है जहां कुछ क्षेत्रों में केवल एक निश्चित संदर्भ में उपयोग किया जाता है की एक बहुत कुछ है।

केवल अन्य अवसर मैं args इस्तेमाल किया जब मैं एक बादल एपीआई के लिए एक XML RPC क्लाइंट का निर्माण किया गया है। चूंकि मैं केवल अंतर्निहित परत पर पैरामीटर पास कर रहा था और जब से गतिशील रूप से उत्पन्न समारोह था, तब मेरे पास * तर्कों का उपयोग करने के अलावा कोई अन्य विकल्प नहीं था क्योंकि मेरे पास पहले से सभी पैरामीटर जानने का कोई तरीका नहीं था।

सबसे मामले में, आप भी यह जरूरत नहीं होगी। मैं इसे किसी और चीज की तुलना में अधिक आलस्य मानता हूं।

कुछ लोग जो से जावा और सी # आता है "पैरामीटर" के लिए एक स्थानापन्न के रूप में उपयोग कर सकते हैं, लेकिन इतने सारे रास्ते अजगर में वैकल्पिक पैरामीटर पारित करने के लिए कर रहे हैं।

और मैं मानता हूँ कि भले ही आप * args उपयोग करते हैं, आप एक बहुत अच्छा प्रलेखन होना चाहिए।

+0

कोडिंग के दो वर्षों में सी # मैंने दो बार 'पैराम्स' का उपयोग किया है। पायथन के एक महीने में, मैंने '(* args, ** kwargs) देखा है 'इतनी बार कि यह मेरी आंखों को खून बहता है। मैं इसे कम से कम इस्तेमाल करने की सिफारिश करेंगे; यह एक ऐसा उपकरण है जिसका प्रयोग एक बहुत ही विशिष्ट समस्या को हल करने के लिए किया जाना चाहिए। और जैसा कि हम जानते हैं, जब आप लोगों को एक उपकरण देते हैं जो उपयोग करना आसान है, तो वे इसका उपयोग नहीं करेंगे और इसका दुरुपयोग नहीं करेंगे। ज़ेन से उद्धरण, – Dagrooms

3

हर कार्य में *args का उपयोग करना है क्योंकि यह (तर्कों की गलत संख्या के साथ एक समारोह बुला) अपने कोड में त्रुटियों मुखौटा कर सकते हैं एक बुरा विचार है। मुझे लगता है कि अंगूठे का नियम केवल *args अगर आप जरूरत*args उपयोग करने के लिए होना चाहिए।

2

वहाँ *args उपयोग करने के लिए कोई बाध्यकारी कारण है है, यह अवधारणा का दुरुपयोग है। आम तौर पर तर्क के लिए अच्छे नाम होते हैं, जो समझ में मदद करते हैं। यहां तक ​​कि जब भी नहीं हैं, (x, y, z) आपको (*args) से अधिक बताता है।

और कोड अधिक पठनीय बनाने से परे, यह भी (जैसे अगर आप (2, 3) के साथ एक (x, y, z) फ़ंक्शन को कॉल आप बल्कि गहरी समारोह के अंदर से कॉल पर एक त्रुटि मिल जाएगा,) त्रुटियों को पकड़ने के लिए मदद करता है, यह आमतौर पर अधिक संक्षिप्त है , और यह भी अधिक कुशल हो सकता है।

लेकिन वहाँ कभी कभी *args के व्यापक उपयोग के लिए सम्मोहक कारण हैं।

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

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

3

Zen of Python में, हम निहित पर स्पष्ट पसंद करते हैं करने के लिए कहा जाता है। जब भी संभव हो तो स्पष्ट तर्कों का उपयोग किया जाना चाहिए।

+1

+1। – nneonneo

+1

@nneonneo ज़ेन से कोई और टिप्पणी नहीं के साथ उद्धरण बहुत बेकार है। पायथन के जेन में दिशानिर्देश बहुत अच्छे हैं, लेकिन सिर्फ इसलिए नहीं कि वे जेन ऑफ पायथन में हैं, वे * अच्छे कारणों * के लिए अच्छे विचार हैं। बिना दिशानिर्देशों के कारण * समझने के कारण पाइथन के जेन को याद रखना (ताकि आप उनसे प्रस्थान करते समय पहचान सकें) आपको उन्हें अच्छी तरह से लागू करने में मदद नहीं करते हैं। – Ben

+0

@ बेन, मुझे नहीं लगता था कि यह अनुमान लगाने के लिए मेरा स्थान था कि वह विशेष आइटम जेन में क्यों है। इस मामले में मैंने सोचा कि यह बहुत स्पष्ट था - समझना और पालन करना स्पष्ट है। मैंने यह भी पाया है कि आपके प्लेटफार्म डिजाइनर को मार्गदर्शन करने वाले सिद्धांतों के साथ काम करना सिर्फ चीजों को बेहतर बनाता है, सिर्फ पायथन में नहीं। –

2

आप एक अज्ञात समारोह (कार्यों सज्जाकार द्वारा वापस अक्सर ऐसा करते हैं) लपेटकर रहे हैं, तो आप अक्सर (*args, **kwargs) उपयोग करने के लिए की जरूरत है।

कुछ वर्ग पदानुक्रम (*args, **kwargs) का उपयोग उन विधियों में करते हैं जिन्हें पदानुक्रमों में विभिन्न वर्गों पर विभिन्न हस्ताक्षरों की आवश्यकता हो सकती है (__init__ एक प्रमुख अपराधी है)। यह वास्तव में सहायक है यदि आप इससे बच सकते हैं, लेकिन कई विरासत पदानुक्रमों के साथ काम करने के लिए आवश्यक हो सकता है (या कम से कम एकाधिक विरासत के साथ जितना संभव हो सके)।

मैं कभी-कभी **kwargs का उपयोग कर समाप्त करता हूं जब मेरे पास बड़ी संख्या में वैकल्पिक तर्क होते हैं, लेकिन इसके लिए बहुत सारे दस्तावेज़ों की आवश्यकता होती है।

एक समारोह है कि (, एक अज्ञात हस्ताक्षर के साथ कुछ अन्य कार्य करने के लिए उन्हें गुजर डेकोरेटर या वर्ग विरासत मामलों में के रूप में के बजाय) *args खुद लेने वाली है, फिर मुझे लगता है कि करने के लिए है कि *args को छोड़कर लगभग कभी नहीं इस्तेमाल किया जाना चाहिए करते हैं मतलब "एक ही तरह की चीज़ के शून्य या अधिक"। और उस स्थिति में आपको इसे *websites या *spaceships या *watermelons नामित करना चाहिए, *args नहीं। असंबद्ध मानकों का एक समूह *args में squashed नहीं किया जाना चाहिए। फ़ंक्शन के लिए *args का उपयोग करने के लिए और भी बदतर होगा "x, a y, और z, या अन्यथा x और z", जहां दूसरा पैरामीटर अलग-अलग चीजें करता है, इस पर निर्भर करता है कि कितने पैरामीटर पारित किए गए हैं। उस बिंदु पर उन्हें स्पष्ट रूप से सभी नाम और डिफ़ॉल्ट होना चाहिए (भले ही यह मानक None डिफ़ॉल्ट हो, फिर उस फ़ंक्शन में देखें जो गैर- None पैटर्न हैं) और स्थिति के बजाए कीवर्ड द्वारा पारित किया जाना चाहिए।