पायथन में कोडिंग के लिए Google टिप्स। भाग दो: स्रोत कोड स्वरूपण युक्तियाँ

अर्धविरामों के साथ अपनी रेखाओं को अलग न करें या अर्धविरामों को एक ही पंक्ति में अलग-अलग कमांड का उपयोग न करें।

अपवाद

• लंबे आयात तार
• टिप्पणियों में URL

बैकस्लैश का उपयोग एक नई रेखा के रूप में न करें। कोष्ठक और ब्रेसिज़ के साथ पायथन के स्पष्ट स्ट्रिंग संयोजन का उपयोग करें। यदि आवश्यक हो, तो आप अभिव्यक्ति के चारों ओर एक अतिरिक्त जोड़ी कोष्ठक जोड़ सकते हैं।

अच्छा:

foo_bar(self, width, height, color='black', design=None, x='foo', emphasis=None, highlight=0) if (width == 0 and height == 0 and color == 'red' and emphasis == 'strong'): 

जब आपका पाठ एक पंक्ति में फिट नहीं होता है, तो स्पष्ट रूप से लाइनों को स्पष्ट करने के लिए कोष्ठक का उपयोग करें।

 x = ('This will build a very long long ' 'long long long long long long string') 

टिप्पणियों के लिए, एक पंक्ति में, यदि आवश्यक हो, तो एक लंबा URL डालें।

अच्छा:

  # See details at # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html 

खराब:

  # See details at # http://www.example.com/us/developer/documentation/api/content/\ # v2.0/csv_file_name_extension_full_specification.html 

ऊपर लाइन में तत्व के इंडेंटेशन पर ध्यान दें (अधिक विवरण के लिए इंडेंटेशन अनुभाग देखें)।

यदि आप पंक्ति विराम को व्यवस्थित नहीं करना चाहते हैं तो उनका उपयोग (कोष्ठक) वापसी अभिव्यक्ति के साथ या सशर्त निर्माण के साथ न करें। (ऊपर देखें)। हालाँकि, कोष्ठक टुपल्स बनाने के लिए अच्छे हैं।

अच्छा:

 if foo: bar() while x: x = bar() if x and y: bar() if not x: bar() return foo for (x, y) in dict.items(): ... 

खराब:

 if (x): bar() if not(x): bar() return (foo) 

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

अच्छा:

 # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four) # 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four) 

खराब:

 # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four) # 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four) 

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

किसी भी कोष्ठक के अंदर कोई स्थान नहीं।
अच्छा: स्पैम (हैम [1], {अंडे: 2}, [])
ख़राब: स्पैम (हैम [1], {अंडे: 2}, [])

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

अच्छा:

 if x == 4: print x, y x, y = y, x 

खराब:

 if x == 4 : print x , y x , y = y , x 

ओपनिंग ब्रैकेट से पहले कोई स्पेस नहीं है जो लॉजिक लिस्ट, इंडेक्स या स्लाइस शुरू करता है।
अच्छा: स्पैम (1)
खराब: स्पैम (1)
अच्छा: तानाशाह ['की'] = सूची [सूचकांक]
बुरा: तानाशाह ['की'] = सूची [सूचकांक]
प्रत्येक तरफ सिंगल स्पेस के साथ बाइनरी ऑपरेटरों को घेरें, यह असाइनमेंट ( = ), तुलना ऑपरेटरों ( ==, <,>, =!, <>, <=>, = में, में, नहीं है, नहीं है ), और बूलियन ऑपरेटर (और, या, नहीं)। आपको लगता है कि सही वातावरण का उपयोग करें
अंकगणित ऑपरेटरों के संबंध में रिक्त स्थान, लेकिन हमेशा बाइनरी ऑपरेटर के दोनों तरफ रिक्त स्थान रखने से आपके कोड को अखंडता मिलेगी।
गुड: x == १
बुरा: x <१
नामित तर्क या डिफ़ॉल्ट मान को इंगित करने के लिए इसका उपयोग करते समय = साइन के किनारों पर रिक्त स्थान का उपयोग न करें।

अच्छा:

 def complex(real, imag=0.0): return magic(r=real, i=imag) 

खराब:

 def complex(real, imag = 0.0): return magic(r = real, i = imag) 

लगातार लाइनों के टुकड़ों को लंबवत संरेखित करने के लिए रिक्त स्थान का उपयोग न करें, क्योंकि संरेखण बोझ हैं। (इस पर लागू होता है : #, =, आदि):

अच्छा:

 foo = 1000 # comment long_name = 2 # comment that should not be aligned dictionary = { 'foo': 1, 'long_name': 2, } 

खराब:

  foo = 1000 # comment long_name = 2 # comment that should not be aligned dictionary = { 'foo' : 1, 'long_name': 2, } 

#! / Usr / bin / python के साथ मुख्य प्रोग्राम फ़ाइल चलाएँ। इस लाइन का उपयोग कर्नेल द्वारा पायथन इंटरप्रेटर को खोजने के लिए किया जाता है, लेकिन जब मॉड्यूल आयात किया जाता है तो पायथन द्वारा इसे अनदेखा कर दिया जाता है। यह सीधे चलाने वाली फ़ाइल के लिए आवश्यक है।

मॉड्यूल, फ़ंक्शन, विधि, या स्ट्रिंग टिप्पणी के लिए सही शैली का उपयोग करना सुनिश्चित करें।

प्रलेखन लाइनें।

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

मॉड्यूल

प्रत्येक फ़ाइल में एक लाइसेंस टेम्पलेट होना चाहिए। अपनी परियोजना के लिए उपयुक्त लाइसेंस टेम्पलेट चुनें। (उदाहरण के लिए, अपाचे 2.0, बीएसडी, एलजीपीएल, जीपीएल)।

कार्य और तरीके

इस खंड में प्रयुक्त शब्द (कार्य) विधियों, कार्यों और जनरेटर को संदर्भित करता है।
समारोह में सभी मामलों में एक दस्तावेजीकरण लाइन होनी चाहिए, जो नीचे वर्णित है:

• मॉड्यूल के बाहर से दिखाई नहीं देता
• बहुत ही कम
• स्पष्ट (पढ़ने में आसान)

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

 def fetch_bigtable_rows(big_table, keys, other_silly_variable=None): """Fetches rows from a Bigtable. Retrieves rows pertaining to the given keys from the Table instance represented by big_table. Silly things may happen if other_silly_variable is not None. Args: big_table: An open Bigtable Table instance. keys: A sequence of strings representing the key of each table row to fetch. other_silly_variable: Another optional variable, that has a much longer name than the other args, and which does nothing. Returns: A dict mapping keys to the corresponding table row data fetched. Each row is represented as a tuple of strings. For example: {'Serak': ('Rigel VII', 'Preparer'), 'Zim': ('Irk', 'Invader'), 'Lrrr': ('Omicron Persei 8', 'Emperor')} If a key from the keys argument is missing from the dictionary, then that row was not found in the table. Raises: IOError: An error occurred accessing the bigtable.Table object. """ pass 

कक्षाएं

कक्षाओं में उनकी घोषणा के नीचे एक दस्तावेजीकरण रेखा होनी चाहिए। यदि आपकी कक्षा में सार्वजनिक विशेषताएँ हैं, तो उन्हें तुरंत विशेषताएँ अनुभाग में प्रलेखित किया जाना चाहिए और उसी स्वरूपण शैली का पालन करना चाहिए जैसे कि आर्ग्स अनुभाग।

 class SampleClass(object): """Summary of class here. Longer class information.... Longer class information.... Attributes: likes_spam: A boolean indicating if we like SPAM or not. eggs: An integer count of the eggs we have laid. """ def __init__(self, likes_spam=False): """Inits SampleClass with blah.""" self.likes_spam = likes_spam self.eggs = 0 def public_method(self): """Performs operation blah.""" 

ब्लॉक और इनलाइन टिप्पणियां

अंतिम स्थान टिप्पणियों में कोड में मुश्किल स्थान होना चाहिए। यदि आप अपनी अगली कोड समीक्षा में उन्हें स्पष्ट करना चाहते हैं, तो आपको अभी उन पर टिप्पणी करनी चाहिए। जटिल ऑपरेशन जो इसे निष्पादित करने से पहले प्रलेखन की कई लाइनें लेते हैं। निहित भागों में पंक्ति के अंत में एक टिप्पणी होनी चाहिए।

 # We use a weighted dictionary search to find out where i is in # the array. We extrapolate position based on the largest num # in the array and the array size and then do binary search to # get the exact number. if i & (i-1) == 0: # true iff i is a power of 2 

पठनीयता में सुधार करने के लिए, ऐसी टिप्पणियों को कोड से कम से कम 2 स्थान होना चाहिए। दूसरी ओर, कोड का वर्णन बिल्कुल नहीं करना बेहतर है। मान लें कि इस कोड को पढ़ने वाला व्यक्ति पाइथन को जानता है (और नहीं कि आपने क्या करने की कोशिश की थी) आपसे बेहतर है।

 # BAD COMMENT: Now go through the b array and make sure whenever i occurs # the next element is i+1 

यह नेस्टेड कक्षाओं पर भी लागू होता है।

अच्छा:

 class SampleClass(object): pass class OuterClass(object): class InnerClass(object): pass class ChildClass(ParentClass): """Explicitly inherits from another class already.""" 

खराब:

 class SampleClass: pass class OuterClass: class InnerClass: pass 

ऑब्जेक्ट क्लास से इनहेरिट करना आवश्यक है ताकि गुण सही तरीके से काम कर सकें, और आपके कोड को Python 3000 के साथ संभावित असंगतताओं से बचाएंगे। यह विशेष विधियों को भी परिभाषित करता है जो ऑब्जेक्ट के मानक शब्दार्थ को लागू करते हैं, उदाहरण के लिए: __n____, __init__, __delattr__, __getattribute__ ,____attattrr , __repr__, और __str__ ।

स्ट्रिंग को स्वरूपित करने के लिए% ऑपरेटर का उपयोग करें, भले ही सभी पैरामीटर स्ट्रिंग्स हों। % ऑपरेटर के बजाय + ऑपरेटर का उपयोग करने पर सावधानीपूर्वक विचार करें।

अच्छा:

 x = a + b x = '%s, %s!' % (imperative, expletive) x = 'name: %s; score: %d' % (name, n) 

खराब:

 x = '%s%s' % (a, b) # use + in this case x = imperative + ', ' + expletive + '!' x = 'name: ' + name + '; score: ' + str(n) 

एक लूप के साथ स्ट्रिंग को समतल करने के लिए + और + = ऑपरेटरों के उपयोग से बचें, जैसा कि तार एक अपरिवर्तनीय डेटा प्रकार हैं, यह दृष्टिकोण अनावश्यक वस्तुओं को बनाता है और रैखिक कानून के बजाय एक द्विघात के अनुसार रनटाइम को बढ़ाता है। इसके बजाय, बस सूची में प्रत्येक प्रतिस्थापन जोड़ें और लूप खत्म होने के बाद ज्वाइन विधि का उपयोग करें (या प्रत्येक स्ट्रिंग को cStringIO.StringIO बफर में लिखें)

अच्छा:

 items = ['<table>'] for last_name, first_name in employee_list: items.append('<tr><td>%s, %s</td></tr>' % (last_name, first_name)) items.append('</table>') employee_table = ''.join(items) 

खराब:

 employee_table = '<table>' for last_name, first_name in employee_list: employee_table += '<tr><td>%s, %s</td></tr>' % (last_name, first_name) employee_table += '</table>' 

"" के बजाय मल्टी-लाइन स्ट्रिंग्स के लिए "" "" का उपयोग करें। ध्यान दें, हालांकि, स्पष्ट स्ट्रिंग संयोजन का उपयोग करना हमेशा बेहतर होता है, जैसा कि एक ही इंडेंटेशन के साथ कार्यक्रम के अंत तक मल्टीलाइन लाइनें जारी नहीं होती हैं।

अच्छा:

 print ("This is much nicer.\n" "Do it this way.\n") 

खराब:

 print """This is pretty ugly. Don't do this. """ 

खुली फ़ाइलों, सॉकेट्स और अन्य फ़ाइल-आकार की वस्तुओं की उपेक्षा करने के कई दुष्प्रभाव होते हैं, जैसे:

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

यदि वे वास्तव में बंद हैं, तो पढ़ने या लिखने का प्रयास एक अपवाद को फेंक देगा, जिससे समस्या का बहुत जल्दी पता चल जाएगा। इसके अलावा, फ़ाइल और सॉकेट्स स्वचालित रूप से बंद हो जाते हैं जब ऑब्जेक्ट के निर्माता को बुलाया जाता है, लेकिन फ़ाइल के राज्य के साथ किसी ऑब्जेक्ट के जीवनकाल को जोड़ना निम्नलिखित कारणों से खराब अभ्यास है:

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

 with open("hello.txt") as hello_file: for line in hello_file: print line 

लूप जैसी वस्तुएं जो निर्माण के साथ समर्थन नहीं करती हैं और Referencelib.closing () का उपयोग करती हैं

 import contextlib with contextlib.closing(urllib.urlopen("http://www.python.org/")) as front_page: for line in front_page: print line 

पायथन 2.5 के तहत लिखा गया पुराना कोड __ Future__ इंपोर्ट से with_statement से आयात के साथ निर्माण के उपयोग को सक्षम कर सकता है।

TODO टिप्पणियों में प्रत्येक टिप्पणी की शुरुआत में एक TODO लाइन शामिल होनी चाहिए, उसके बाद एक नाम, ईमेल पता या अन्य पहचानकर्ता जो कि कोष्ठक में इंगित समस्या का समाधान प्रदान करने में सक्षम है। बिंदु वैकल्पिक है। एक टिप्पणी जो यह बताती है कि वहाँ क्या होना चाहिए, इसकी आवश्यकता नहीं है। मुख्य लक्ष्य TODO के लिए एक सामान्य प्रारूप है, जो जल्दी से एक विशिष्ट व्यक्ति को ढूंढेगा जो समस्या का अधिक विस्तृत विवरण प्रदान कर सकता है। TODO एक गारंटी नहीं है कि कोई व्यक्ति इस समस्या को हल करेगा। इस प्रकार, जब आप TODO बनाते हैं, तो इसमें लगभग हमेशा केवल आपका नाम होता है।

 # TODO(kl@gmail.com): Use a "*" here for string repetition. # TODO(Zeke) Change this to use relations. If your TODO is of the form "At a future date do something" make sure that you either include a very specific date ("Fix by November 2009") or a very specific event ("Remove this code when all clients can handle XML responses."). 

अच्छा:

 import os import sys 

खराब:

 import os, sys 

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

• मानक पुस्तकालय से आयात
• तृतीय-पक्ष आयात
• अपने आवेदन पुस्तकालयों से आयात करें

समूहीकरण के साथ-साथ, आयात को प्रत्येक मॉड्यूल के पूर्ण पथ के अनुसार, मामले-संवेदी नहीं, लेक्सोग्राफिक रूप से सॉर्ट किया जाना चाहिए।

 import foo from foo import bar from foo.bar import baz from foo.bar import Quux from Foob import ar 

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

 if foo: bar(foo) 

खराब:

 if foo: bar(foo) else: baz(foo) try: bar(foo) except ValueError: baz(foo) try: bar(foo) except ValueError: baz(foo) 

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

मॉड्यूल_नाम, पैकेज_नाम, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, example_var_name, function_parameter_name, local_var_name।

नाम से बचें:

• काउंटरों या पुनरावृत्तियों को छोड़कर एकल-चरित्र नाम
• मॉड्यूल और पैकेज के नाम में विपक्ष।
• डबल अंडरस्कोर (शुरुआत और नामों के अंत में) भाषा के लिए आरक्षित हैं।

नामकरण सम्मेलन

• "आंतरिक" - इसका मतलब है कि मॉड्यूल, संरक्षित या निजी वर्ग के लिए आंतरिक।
• अग्रणी अंडरस्कोर (_) प्रतिस्थापन संरक्षित मॉड्यूल चर और कार्यों के लिए समर्थित है (जो आयात से आयात नहीं किए जाते हैं *)
• एक चर या विधि के नाम के साथ दोहरे अग्रणी अंडरस्कोर (__) को प्रभावी ढंग से इस वर्ग के लिए निजी बनाता है (नाम के अतिरिक्त) का उपयोग करता है। संबंधित कक्षाओं और शीर्ष-स्तरीय स्तरों को एक मॉड्यूल में एक साथ रखना। जावा के विपरीत, एक मॉड्यूल में एक वर्ग बनाने के लिए खुद को सीमित करने की आवश्यकता नहीं है।
• नामकरण कक्षाओं के लिए ऊंट संकेतन का उपयोग करें, और बड़े अक्षरों के साथ अंकन और मॉड्यूल नामों के लिए अंडरस्कोर। हालांकि कई मॉड्यूल हैं जो नामकरण के लिए ऊंट संकेतन का उपयोग करते हैं, यह ऐसा करने के लिए अनुशंसित नहीं है, क्योंकि यह भ्रामक हो सकता है, क्योंकि मॉड्यूल का नाम वर्ग के नाम पर रखा गया है। (रुको, क्या मैंने आयात स्ट्रिंग लिखा है या स्ट्रिंगआईआईओ आयात स्ट्रिंगिंगो से?)

गुइडो सिफारिशों के आधार पर शैलियाँ:

टाइप	बाहरी	आंतरिक
संकुल	lower_with_under
मॉड्यूल	lower_with_under	_lower_with_under
कक्षाएं	CapWords	_CapWords
अपवाद	CapWords
कार्यों	लोअर_विथ_उंडर ()	_lower_with_under ()
ग्लोबल / इंट्राक्लास कांस्टेंट	CAPS_WITH_UNDER	_CAPS_WITH_UNDER
वैश्विक / उपवर्ग चर	lower_with_under	_lower_with_under
कक्षा उदाहरण चर	lower_with_under	_lower_with_under (संरक्षित) या __lower_with_under (निजी)
विधि नाम	लोअर_विथ_उंडर ()	_lower_with_under () (संरक्षित) या __lower_with_under () (निजी)
कार्य / विधि तर्क	lower_with_under
स्थानीय चर	lower_with_under

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

 def main(): ... if __name__ == '__main__': main() 

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

यदि आप किसी और के कोड को संपादित कर रहे हैं, तो इस कोड को देखने के लिए कुछ मिनटों का समय लें और अपने लिए लेखन शैली चुनें। यदि प्रत्येक कथन रिक्त स्थान से घिरा हुआ है, तो आपको यह भी करना चाहिए। , (#) , . , , , .
, , . , — , . .