📢 🤲 👨🏽‍⚕️ पायथन में इंडेंटेशन - समाधान विकल्प ❓ 👩🏼‍🤝‍👨🏾 🌰

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

ऐसा लगता है कि पायथन के मामले में, ऐसा ऑपरेशन संभव नहीं है।

कम से कम मैं पायथन में बेतरतीब ढंग से ऑफसेट इंडेंट का तुरंत पता लगाने के लिए कहीं भी नहीं मिला। मुझे खुद इस समस्या को हल करना था।

परिचय

प्रिय पाठक!
यदि कथन आपके करीब है:
1) यह प्रोग्रामिंग एक उच्च कला है।
2) कि किसी भी भाषा में प्रोग्रामिंग करते समय आपको स्रोत कोड को कम करने के लिए इस भाषा की शक्ति और विविधता का अधिकतम उपयोग करना होगा।
3) यह कि प्रोग्रामिंग करते समय, आपको कार्यक्रम के स्रोत कोड में अपना उच्च स्तर दिखाना होगा ताकि कोई भी आपके कार्यक्रम के बारे में यह न कह सके कि यह "गूंगा" है।

यदि उपरोक्त बिंदुओं में से कम से कम एक (!) आपके करीब है, तो कृपया इस लेख को न पढ़ें! कृपया इस पर अपना समय बर्बाद न करें।
यह प्रोग्रामिंग के एक पूरी तरह से दूर और बेतुके क्षण के बारे में बात करेगा।

प्रिय पाठक!
यदि कथन पहले से ही आपके पास है:
1) यह प्रोग्रामिंग एक नियमित, बल्कि नीरस काम है, जैसे एक अंतहीन घुमावदार खाई को खोदना।
2) कि किसी भी भाषा में प्रोग्रामिंग करते समय, आपको भाषा कमांड के एक निश्चित न्यूनतम-इष्टतम सेट का उपयोग करने की आवश्यकता होती है (संभवतः इसके अधिकांश आदेशों को छोड़ना) ताकि एक जूनियर प्रोग्रामर भी आसानी से आपके प्रोग्राम का पता लगा सके!
3) जब आपके प्रोग्राम को प्रोग्रामिंग कुछ हद तक "गूंगा" होना चाहिए। ताकि आप इसे लागू करने के बाद, आप एक नई परियोजना शुरू कर सकें और शांति से जूनियर प्रोग्रामर को शामिल कर सकें, जिन्होंने ग्राहक की नियमित छोटी नई आवश्यकताओं के तहत इसका समर्थन करने और उसे परिष्कृत करने के लिए परियोजना में भाग लिया।

यदि ऊपर दिए गए ये तीनों कथन आपके लिए सही हैं, तो शायद आपके पास एक समस्या है, जिसका समाधान मैं प्रस्तुत करना चाहता हूं।

पायथन के मुख्य नुकसान:

1) संसाधनों और इसके डेटा के उपयोग में पायथन को "कम से कम नहीं" किया जाता है और इसलिए, ऐसे प्रोग्राम लिखने के लिए उपयुक्त नहीं है जिन्हें संसाधन उपयोग की आवश्यकता होती है, जैसे कि मोबाइल एप्लिकेशन, निम्न-स्तरीय प्रोग्राम (ड्राइवर, निवासी प्रोग्राम आदि)। ।) आदि।

2) पायथन धीमा और एकल-थ्रेडेड (GIL - ग्लोबल इंटरप्रेटर लॉक) है।

3) पायथन में, प्रोग्राम ब्लॉक इंडेंटेशन पर केवल (!) आधारित हैं। होने के कारण:

कार्यक्रमों की "पठनीयता" घट जाती है (नीचे देखें);
स्रोत पाठ का पूर्ण ऑटोफ़ॉर्मिंग असंभव है;
एक आकस्मिक और अनिर्दिष्ट ऑफसेट के साथ होने वाली त्रुटि की संभावना है, जो कभी-कभी बहुत मुश्किल से सही और सही पाई जाती है।

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

पायथन का दूसरा दोष यह है कि इसमें C / C ++ के साथ दोतरफा उत्कृष्ट अंतर है।

अक्सर एक सफल परियोजना काफी तेजी से विकसित हो रही है। और सबसे पहले कोई उच्च प्रदर्शन आवश्यकताएं नहीं हैं, और पायथन में, यदि आवश्यक हो तो C / C ++ में छोटे आवेषण का उपयोग किया जाता है।
लेकिन जैसे-जैसे यह परियोजना विकसित होती है और फैलती है, प्रदर्शन की आवश्यकताओं के अनुसार वृद्धि होती है, और पायथन अधिक से अधिक बार C / C ++ से भाषा के कार्यों को पूरा करना शुरू करता है। उसी समय, पायथन की भूमिका में ही कमी नहीं होती है, जैसा कि जब प्रोग्रामिंग अनुभागों को उच्च निष्पादन गति की आवश्यकता नहीं होती है (और आमतौर पर बड़ी परियोजनाओं में उनमें से बहुत सारे होते हैं), पायथन सी / सी ++ की तुलना में अधिक सुविधाजनक उपकरण है।

और पायथन की तीसरी खामी के लिए, मैं अपने समाधान की पेशकश करना चाहूंगा।

आप सभी जानते हैं कि भाषाओं के विशाल बहुमत के लिए स्रोत पाठ ऑटो-प्रारूप बहुत बार उपयोग किया जाता है।

उन। कोई फर्क नहीं पड़ता कि इस भाषा में कोई इंडेंटेशन क्या लिखा जाता है, जब आप ऑटोफ़ॉर्मेटिंग शुरू करते हैं, तो सभी इंडेंटेशन को उसके मानक रूप में लाया जाएगा। अजगर के लिए, यह असंभव लगता है।

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

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

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

इस मामले में, आप निश्चित रूप से, स्रोत पाठ (परिवर्तनों से पहले) देख सकते हैं, लेकिन यदि आपने पहले से ही इस जगह में बहुत सारे सुधार किए हैं, तो आपको सुधारों की इस पूरी श्रृंखला को "खोलना" होगा।

पायथन में इंडेंटेशन समस्या का समाधान

पायथन में इंडेंटेशन निम्न आदेशों द्वारा बनता है:

- class
- def

- for
- while

- if

- try

- with

और इंडेंटेशन पर निर्भरता को हटाने के लिए, इनमें से प्रत्येक कमांड के लिए मैंने "अंतिम" कमांड का उपयोग करने के लिए एक नियम बनाने का फैसला किया, जो निश्चित रूप से कमांड्स (इंडेंटेशन) के ब्लॉक को बंद कर देगा।

क्लास और डिमांड्स

क्लास / डिफ कमांड के लिए, आमतौर पर इंडेंटेशन ब्लॉक को पूरा करने में कोई समस्या नहीं होती है ब्लॉक नए वर्ग / डीफ़ कमांड के साथ बंद है।

एकमात्र मामला दूसरे उपप्रोग्राम / विधि के अंदर घोषित एक या एक से अधिक उपप्रोग्राम की उपस्थिति है।

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
        ...  ppg_3 ...
        ...  ppg_3 ...
    ...  ppg_1 ...

फिर, यदि आप गलती से पिछले आंतरिक उपप्रोग्राम के निर्देशों के ब्लॉक को स्थानांतरित करते हैं, तो यह उपप्रोग्राम / विधि के कमांड के साथ विलय करेगा जिसमें यह आंतरिक उपप्रोग्राम घोषित किया गया है।

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
    ...  ppg_3 ...
    ...  ppg_3 ...
    ...  ppg_1 ...

इस मामले में, इस आंतरिक दिनचर्या / विधि के अंत में आपको केवल "रिटर्न" डालने की आवश्यकता है, जो स्पष्ट रूप से इसके आदेशों के ब्लॉक के अंत का संकेत देगा।

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
        ...  ppg_3 ...
        ...  ppg_3 ...
        return
    ...  ppg_1 ...

के लिए और जब आदेश

"फॉर" और "जबकि" स्टेटमेंट्स के अंत में आपको "जारी" रखने की आवश्यकता होती है।

उन। कमांड इस तरह दिखेगा:

for  <...> :             #  
    ...  ....
    continue             #

तथा

while  <...> :           #  
    ...  ....
    continue             #

उदाहरण के लिए:

        ...  ...

        for i in range(10):
            ...  for ...

            ...  for  ...

            ...  for  ...

        ...  ...

गलती से "फॉर" ब्लॉक के अंतिम कमांड्स में इंडेंटेशन को हटाने से प्रोग्राम एक्जीक्यूशन एरर नहीं होता है, बल्कि गलत परिणाम आते हैं! और इस तरह की विफलता को खोजने के लिए बहुत मुश्किल है यदि आप कार्यक्रम के एल्गोरिथ्म को नहीं जानते हैं (उदाहरण के लिए, यदि यह एक सेवानिवृत्त सहयोगी का कार्यक्रम है)!

ऐसे:

        ...  ...

        for i in range(10):
            ...  for ...

        ...  for  ...

        ...  for  ...

        ...  ...

और नीचे दिए गए उदाहरण में, गलती से इंडेंट को हटाने से तुरंत एक त्रुटि होगी:

        ...  ...

        for i in range(10):
            ...  for ...

            ...  for  ...

            ...  for  ...

            continue

        ...  ...

अगर आज्ञा

"यदि" कथन के अंत में, आपको कमांड "एलिफ 0: पास" लगाने की आवश्यकता है, और इसके बजाय "और" के बजाय "एलिफ 1:" कमांड का उपयोग करें।

उन। "अगर" के लिए आदेशों का एक पूरा ब्लॉक होगा:

if <>                      #  
    ...  ....
elif <>
    ...  ....
elif 1:                    #  "else"
    ...  ....
elif 0: pass               #

उदाहरण के लिए:

        ...  ...

        if  result != -1 :

            ...  if ...

            ...  if ...

            ...  if ...

        elif 0: pass

        ...  ...

यदि आप इसे ऊपर दिखाए अनुसार बनाते हैं, तो "if ... elif 0: पास" कमांड ब्लॉक में, इंडेंटेशन एक स्टार्टअप त्रुटि उत्पन्न करेगा।

"एलिफ़ 0: पास" के बिना, यदि तब "अगर" ब्लॉक की अंतिम पंक्तियों में इंडेंट गलती से हटा दिए जाते हैं, तो आप पहले उस जगह की तलाश करेंगे जिसके कारण प्रोग्राम गलत तरीके से काम करना शुरू कर देता है, और फिर सोचें कि ब्लॉक में कौन से इंडेंट होने चाहिए और कौन से - नहीं।

        ...  ...

        if  result != -1 :

            ...  if ...

        ...  if ...

        ...  if ...

        ...  ...

मेरे विचार में, संचालकों द्वारा "के लिए",
"जबकि", "अगर", आदि ... द्वारा बनाए गए आदेशों के ब्लॉक को बंद करने की सलाह दी जाती है ,

क्योंकि जब आप कोड के एक खंड को देखते हैं, जहां
वर्तमान के बहुत अंत के बीच इंडिकेशन के स्तर में एक बड़ा अंतर होता है। ब्लॉक करें और अगले की शुरुआत में, आप अक्सर समझ नहीं सकते हैं कि किस इंडेंटेशन से संबंधित है।

फिर "जारी रखें" और "एलिफ 0: पास" के साथ निर्माण, आकस्मिक विलोपन से बचाने के अलावा, आपको यह भी इंगित करने की अनुमति देगा कि कौन सी इकाई शुरू की गई है और इस पर एक टिप्पणी लिखें ।

उदाहरण के लिए, आप एक बड़े ब्लॉक का अंत देखते हैं:

                            ...  ...

                            ...  ...

                            ...  ...

                            ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

    elif result == 1 :

        ...  ...

        ...  ...

        ...  ...

        ...  ...

और यह याद रखना मुश्किल है कि प्रत्येक इंडेंटेशन स्तर का मतलब क्या है।

लेकिन यह इस तरह दिखता है जब यह बहुत आसान है:

                            ...  ...

                            ...  ...

                            ...  ...

                            ...  ...

                            continue    #   b'\\r\\n'   

                        ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

                    elif 0: pass     #  " "  " "

                elif 0: pass         #   . - 

                continue             #    

            continue                 #  .,  -  " "
                      
    elif result == 1 :

        ...  ...

        ...  ...

        ...  ...

        ...  ...

कमांड का प्रयास करें

"अगर" के साथ एक पूर्ण सादृश्य है।

try:                   #  
    ...  ....
except <...>:
    ...  ....
except 1:              #  "else"
    ...  ....
except 0: pass         #

एकमात्र समस्या अंत में है: कमांड । इसके बाद, आप वर्तमान ट्राइ-ब्लॉक के किसी भी कमांड को नहीं रख सकते हैं।

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

उन। "आखिरकार:" वाला पाठ इस तरह होगा:

    def my_ppg():
        ...
        return

    ...

    finally:
        my_ppg()

    ...

इस मामले में, आप सुरक्षित रूप से ऑटोफ़ॉर्मेटिंग भी लागू कर सकते हैं और
गलती से इंडेंट डिलीट करने से नहीं डरते ।

“आज्ञा के साथ

पायथन में "के साथ" के लिए कोई अतिरिक्त आदेश नहीं हैं जो एक ब्लॉक के अंत के रूप में सेवा कर सकते हैं। इसलिए, स्थिति अंत के साथ स्थिति के समान है।
उन। या तो हम "सब" के साथ "उप-स्टेटमेंट ब्लॉक" में स्थानीय सबरूटीन पर निष्पादित होने वाली सभी कमांड्स को स्थानांतरित करते हैं, या ... लेकिन फिर मैं बहुत ही निंदनीय बात कहूंगा: "... या आपको बस इसका उपयोग करने की आवश्यकता नहीं है।"

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

निष्कर्ष

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

और अब, एक मुस्कुराहट के साथ, हम इस तरह से सवाल उठाते हैं: "यदि आप इंडेंटेशन ब्लॉक को सही ढंग से प्रारूपित करते हैं, तो क्या पायथन के नुकसान हैं, यदि आवश्यक हो तो C / C ++ के साथ बातचीत करें और मोबाइल और संसाधन-महत्वपूर्ण अनुप्रयोगों में पायथन का उपयोग न करें?"

उत्तर: “केवल छोटी-मोटी खामियाँ। उन। द्वारा और बड़े - नहीं। ”

और इस तरह के सवाल के साथ, हम केवल पायथन के मुख्य लाभों का आनंद ले सकते हैं।

सादगी।
साइटों का न्यूनतम परीक्षण चक्र: लिखित-लॉन्च-चेक किया गया।
पाइथन के लिए पावर - लाइब्रेरी / फ्रेमवर्क "हर स्वाद और रंग के लिए हैं।"

ये तीन फायदे एक साथ, मेरी राय में, भाषा का लगभग सही संस्करण है (यह मत भूलो कि यह केवल ऊपर दिए गए प्रश्न में निर्दिष्ट शर्तों के अधीन है!)।

पायथन में इंडेंटेशन - समाधान विकल्प