PEP 8 के अनुसार टाइप एनोटेशन वाले डिफॉल्ट्स की स्पेसिंग कैसे रखें

PEP 8 के अनुसार जानें: Python पैरामीटर्स में टाइप एनोटेशन और डिफॉल्ट मान के साथ = की स्पेसिंग, यूनियन टाइप्स/Optional का सही उपयोग, व ruff/black फॉर्मैटर टिप्स.

Python फ़ंक्शन पैरामीटर्स में डिफॉल्ट मानों के आसपास की स्पेसिंग तब तक मामूली लगती है, जब तक तस्वीर में टाइप एनोटेशन नहीं आते। उलझन खासकर यूनियन टाइप्स के साथ बढ़ जाती है, जहां डेवलपर सही परंपरा खोजने की उम्मीद में स्पेस और कोष्ठकों के अलग‑अलग संयोजन आज़माते रहते हैं। आइए स्पष्ट करें कि PEP 8 की अपेक्षा क्या है और इसे लगातार कैसे अपनाया जाए।

समस्या का परिदृश्य

एक प्रचलित धारणा है कि पैरामीटर सूची में डिफॉल्ट रखते समय बराबरी के चिन्ह के आसपास स्पेस नहीं होना चाहिए। यह धारणा केवल उन पैरामीटर्स तक सीमित है जिन पर कोई एनोटेशन नहीं है। जैसे ही आप एनोटेशन जोड़ते हैं, नियम बदल जाता है, और यूनियन टाइप्स के साथ शैली से जुड़े सवाल बढ़ जाते हैं।

def setup(name: str="baz"):
    pass
# यूनियन टाइप्स के साथ कौन-सा लेआउट सही है?
def process_payload(token: str | None=None):
    pass
def process_payload(token: str | None = None):
    pass
def process_payload(token: (str | None)=None):
    pass

वास्तव में शैली को क्या नियंत्रित करता है

PEP 8 एनोटेशन और डिफॉल्ट मान के मेलजोल पर स्पष्ट है। निर्देश संक्षिप्त और दोटूक है:

जब किसी आर्ग्युमेंट एनोटेशन को डिफॉल्ट मान के साथ जोड़ा जाए, तो = चिन्ह के दोनों ओर स्पेस का उपयोग करें

यही एक वाक्य समझा देता है कि “बिना स्पेस” की आदत पैरामीटर के एनोटेट होते ही क्यों लागू नहीं रहती। एनोटेटेड स्थिति में बराबरी के चिन्ह के दोनों ओर स्पेस होना चाहिए, जबकि बिना एनोटेशन वाले डिफॉल्ट्स “चिपके हुए” रहते हैं। टाइप्स के चारों ओर कोष्ठक यूनियन के लिए मानक शैली का हिस्सा नहीं हैं; जब तक आप समूहबद्धता पर जोर न देना चाहें, वे आम तौर पर आवश्यक नहीं होते। अगर आप वैकल्पिक मान को दिखाने का अधिक अभिव्यंजक तरीका चाहते हैं, तो साधारण मामलों—जैसे किसी एकल टाइप के साथ None—में आप Optional[...] का उपयोग कर सकते हैं, हालांकि यह पैटर्न मनमाने यूनियनों तक नहीं फैलता।

उपाय

PEP 8 की सिफारिश लागू करते हुए, यूनियन टाइप और डिफॉल्ट वाले फ़ंक्शन सिग्नेचर में बराबरी के चिन्ह के दोनों ओर स्पेस होना चाहिए और अनावश्यक कोष्ठकों से बचना चाहिए।

def process_payload(token: str | None = None):
    pass

अगर आप बड़े कोडबेस को मानकीकृत कर रहे हैं, तो एक फ़ॉर्मैटर समय बचाएगा। ruff या black जैसे टूल स्पेसिंग को एकरूप रखेंगे और रिव्यू के दौरान स्टाइल पर बहस करने का मोह कम करेंगे।

यह क्यों मायने रखता है

एनोटेशन और डिफॉल्ट‑मान की सुसंगत फॉर्मैटिंग पठनीयता बढ़ाती है और सिग्नेचर में अस्पष्टता घटाती है। टूलिंग में भी इसका लाभ मिलता है: लिंटर्स, फ़ॉर्मैटर्स और टाइप चेकर्स तब सबसे अच्छा काम करते हैं जब कोड सहमति वाले नियमों का पालन करता है। बात छोटी लगे, लेकिन समान स्पेसिंग शैली के बहाव को रोकती है और डिफ्स को साफ बनाती है।

मुख्य बातें

एक सरल विभाजन याद रखें: एनोटेटेड पैरामीटर्स में बराबरी के चिन्ह के आसपास स्पेस होते हैं, अनएनोटेटेड में नहीं। यूनियन टाइप्स को कोष्ठकों में न लपेटें, जब तक कि आप जानबूझकर अतिरिक्त समूहबद्धता न दिखा रहे हों। वैकल्पिक एकल‑टाइप पैरामीटर्स के लिए, कुछ संदर्भों में Optional[...] T | None से अधिक स्पष्ट पढ़ाई दे सकता है, जबकि व्यापक यूनियनों के लिए | वाला रूप ही उपयुक्त रहता है। इन विकल्पों को स्थिर रखने के लिए ऑटो‑फ़ॉर्मैटर अपनाएँ, ताकि टीम ध्यान लेआउट के बजाय तर्क पर रख सके।