Django 2.1 - Writing your first patch for Django

Django के लिए अपना पहला पैच लिखना




django

Django के लिए अपना पहला पैच लिखना

परिचय

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

अपने स्वयं के सरोकारों को देखने के लिए Django में स्वयं योगदान देना सबसे अच्छा तरीका है। यह पहली बार में कठिन लग सकता है, लेकिन यह वास्तव में बहुत आसान है। हम आपको पूरी प्रक्रिया से गुजरेंगे, ताकि आप उदाहरण के द्वारा सीख सकें।

यह किसके लिए ट्यूटोरियल है?

यह भी देखें

यदि आप पैच सबमिट करने के तरीके के संदर्भ के लिए देख रहे हैं, तो सबमिटिंग पैच दस्तावेज़ देखें।

इस ट्यूटोरियल के लिए, हम उम्मीद करते हैं कि आपको कम से कम एक बुनियादी समझ है कि Django कैसे काम करता है। इसका मतलब है कि आपको अपना पहला Django ऐप लिखने पर मौजूदा ट्यूटोरियल्स से गुजरने में सहज होना चाहिए। इसके अलावा, आपको पाइथन की अच्छी समझ होनी चाहिए। लेकिन अगर आप नहीं करते हैं, तो पायथॉन प्रोग्रामर की शुरुआत के लिए पाइथन एक शानदार (और मुफ्त) ऑनलाइन किताब है।

आप में से जो संस्करण नियंत्रण प्रणालियों और ट्राक से अपरिचित हैं, वे पाएंगे कि इस ट्यूटोरियल और इसके लिंक में आरंभ करने के लिए पर्याप्त जानकारी शामिल है। हालाँकि, आप शायद इन विभिन्न उपकरणों के बारे में कुछ और पढ़ना चाहते हैं यदि आप नियमित रूप से Django में योगदान करते हैं।

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

सहायता कहां से प्राप्त करें:

यदि आपको इस ट्यूटोरियल से गुजरने में परेशानी हो रही है, तो कृपया django-developers को संदेश पोस्ट करें या irc.freenode.net पर # django-dev द्वारा ड्रॉप करें जो कि अन्य Django उपयोगकर्ताओं के साथ चैट करने में सक्षम हैं जो मदद करने में सक्षम हो सकते हैं।

यह ट्यूटोरियल क्या कवर करता है?

हम पहली बार Django के लिए एक पैच योगदान के माध्यम से आप चल रहा हूँ। इस ट्यूटोरियल के अंत तक, आपको दोनों टूल और शामिल प्रक्रियाओं की एक बुनियादी समझ होनी चाहिए। विशेष रूप से, हम निम्नलिखित को कवर करेंगे:

  • Git स्थापित करना।
  • Django की डेवलपमेंट कॉपी कैसे डाउनलोड करें।
  • Django के परीक्षण सूट में चल रहा है।
  • अपने पैच के लिए एक परीक्षण लिखना।
  • अपने पैच के लिए कोड लिखना।
  • अपने पैच परीक्षण।
  • पुल अनुरोध सबमिट करना।
  • अधिक जानकारी के लिए कहां देखें।

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

अजगर 3 की आवश्यकता!

Django का वर्तमान संस्करण पायथन 2.7 का समर्थन नहीं करता है। पायथन 3 को पायथन के डाउनलोड पृष्ठ पर या अपने ऑपरेटिंग सिस्टम के पैकेज मैनेजर के साथ प्राप्त करें।

विंडोज उपयोगकर्ताओं के लिए

विंडोज पर पायथन स्थापित करते समय, सुनिश्चित करें कि आप "पथ में python.exe जोड़ें" विकल्प की जांच करें, ताकि यह हमेशा कमांड लाइन पर उपलब्ध हो।

आचार संहिता

एक योगदानकर्ता के रूप में, आप हमें Django समुदाय को खुला और समावेशी रखने में मदद कर सकते हैं। कृपया पढ़ें और हमारे आचार संहिता का पालन ​​करें।

Git स्थापित करना

इस ट्यूटोरियल के लिए, आपको Django के वर्तमान विकास संस्करण को डाउनलोड करने और आपके द्वारा किए गए परिवर्तनों के लिए पैच फ़ाइलों को जेनरेट करने के लिए Git इंस्टॉल करना होगा।

यह जांचने के लिए कि आपने Git स्थापित किया है या नहीं, कमांड लाइन में git दर्ज करें। यदि आपको यह कहते हुए संदेश मिलते हैं कि यह कमांड नहीं मिल सका है, तो आपको इसे डाउनलोड और इंस्टॉल करना होगा, Git का डाउनलोड पेज देखें

यदि आप Git से परिचित नहीं हैं, तो आप कमांड लाइन में git help टाइप करके हमेशा इसके कमांड्स (एक बार इंस्टॉल होने के बाद) के बारे में अधिक जानकारी प्राप्त कर सकते हैं।

Django के विकास संस्करण की एक प्रति प्राप्त करना

Django में योगदान करने के लिए पहला कदम स्रोत कोड की एक प्रति प्राप्त करना है। सबसे पहले, GitHub पर Django कांटा । फिर, कमांड लाइन से, उस डायरेक्टरी पर नेविगेट करने के लिए cd कमांड का उपयोग करें, जहाँ आप अपनी स्थानीय कॉपी Django को जीना चाहते हैं।

निम्नलिखित कमांड का उपयोग करके Django स्रोत कोड रिपॉजिटरी डाउनलोड करें:

$ git clone [email protected]:YourGitHubName/django.git
...\> git clone [email protected]:YourGitHubName/django.git

अब जब आपके पास Django की एक स्थानीय प्रतिलिपि है, तो आप इसे वैसे ही स्थापित कर सकते हैं जैसे आप pip का उपयोग करके किसी भी पैकेज को स्थापित करेंगे। ऐसा करने का सबसे सुविधाजनक तरीका एक आभासी वातावरण (या virtualenv) का उपयोग करके है जो पायथन में निर्मित एक विशेषता है जो आपको अपनी प्रत्येक परियोजना के लिए स्थापित पैकेजों की एक अलग निर्देशिका रखने की अनुमति देता है ताकि वे एक दूसरे के साथ हस्तक्षेप न करें ।

अपने घर की निर्देशिका में .virtualenvs/ उदाहरण के लिए, अपने सभी virtualenvs को एक स्थान पर रखना एक अच्छा विचार है। यदि यह अभी तक मौजूद नहीं है, तो इसे बनाएं:

$ mkdir ~/.virtualenvs
...\> mkdir %HOMEPATH%\.virtualenvs

अब रन करके एक नया वर्चुअन बनाएं:

$ python -m venv ~/.virtualenvs/djangodev
...\> py -m venv %HOMEPATH%\.virtualenvs\djangodev

वह रास्ता है जहां नया वातावरण आपके कंप्यूटर पर सहेजा जाएगा।

उबंटू उपयोगकर्ताओं के लिए

उबंटू के कुछ संस्करणों पर उपरोक्त कमांड विफल हो सकती है। इसके बजाय virtualenv पैकेज का उपयोग करें, पहले सुनिश्चित करें कि आपके पास pip3 :

$ sudo apt-get install python3-pip
$ # Prefix the next command with sudo if it gives a permission denied error
$ pip3 install virtualenv
$ virtualenv --python=`which python3` ~/.virtualenvs/djangodev

अपने virtualenv को स्थापित करने का अंतिम चरण इसे सक्रिय करना है:

$ source ~/.virtualenvs/djangodev/bin/activate

यदि source कमांड उपलब्ध नहीं है, तो आप इसके बजाय डॉट का उपयोग करके देख सकते हैं:

$ . ~/.virtualenvs/djangodev/bin/activate

विंडोज उपयोगकर्ताओं के लिए

Windows पर अपने virtualenv को सक्रिय करने के लिए, रन करें:

...\> %HOMEPATH%\.virtualenvs\djangodev\Scripts\activate.bat

जब भी आप एक नया टर्मिनल विंडो खोलते हैं तो आपको virtualenv को सक्रिय करना होगा। virtualenvwrapper इसे और अधिक सुविधाजनक बनाने के लिए एक उपयोगी उपकरण है।

आपके द्वारा अब तक pip माध्यम से जो कुछ भी स्थापित किया गया है, वह आपके नए वर्चुअनव में स्थापित किया जाएगा, जो अन्य वातावरणों और सिस्टम-वाइड पैकेजों से अलग होगा। इसके अलावा, वर्तमान में सक्रिय virtualenv का नाम कमांड लाइन पर प्रदर्शित होता है, जिससे आपको यह पता लगाने में मदद मिलती है कि आप किसका उपयोग कर रहे हैं। आगे बढ़ो और Django के पहले से क्लोन किए गए प्रतिलिपि स्थापित करें:

$ pip install -e /path/to/your/local/clone/django/
...\> pip install -e \path\to\your\local\clone\django\

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

Django के पिछले संशोधन के लिए वापस रोलिंग

इस ट्यूटोरियल के लिए, हम एक केस स्टडी के रूप में टिकट #24788 का उपयोग कर रहे हैं, इसलिए हम उस टिकट के पैच को लागू करने से पहले Django के संस्करण के इतिहास को #24788 देंगे। यह हमें उन सभी चरणों से गुजरने की अनुमति देगा, जिसमें स्क्रैच से उस पैच को लिखना है, जिसमें Django के टेस्ट सूट को चलाना शामिल है।

ध्यान रखें कि जब हम इस ट्यूटोरियल के लिए Django के पुराने संशोधन का उपयोग करेंगे, तो आपको टिकट के लिए अपने स्वयं के पैच पर काम करते समय हमेशा मास्टर शाखा के वर्तमान संस्करण का उपयोग करना चाहिए!

ध्यान दें

इस टिकट के लिए पैच Paweł Marczewski द्वारा लिखा गया था, और इसे 4ango7e8483b2679fc1cba3410f08960bac6f51115 प्रतिबद्ध के रूप में Django पर लागू किया गया था। नतीजतन, हम अभी से पहले Django के संशोधन का उपयोग करेंगे, 4ccfc4439a7add24f8db4ef3960d02ef8ae09887 प्रतिबद्ध करें

Django के रूट डायरेक्टरी में नेविगेट करें (वह है जिसमें django , docs , tests , AUTHORS , आदि शामिल हैं)। फिर आप Django के पुराने संशोधन को देख सकते हैं जिसका उपयोग हम नीचे दिए गए ट्यूटोरियल में करेंगे:

$ git checkout 4ccfc4439a7add24f8db4ef3960d02ef8ae09887
...\> git checkout 4ccfc4439a7add24f8db4ef3960d02ef8ae09887

पहली बार चल रहा है Django का टेस्ट सूट

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

परीक्षण सूट चलाने से पहले, Django tests/ निर्देशिका में पहले cd द्वारा अपनी निर्भरता स्थापित करें और फिर चल रहा है:

$ pip install -r requirements/py3.txt
...\> pip install -r requirements\py3.txt

यदि आपको स्थापना के दौरान कोई त्रुटि आती है, तो हो सकता है कि आपका सिस्टम एक या अधिक पायथन पैकेजों के लिए निर्भरता खो रहा हो। विफल पैकेज के दस्तावेज़ से परामर्श करें या त्रुटि संदेश के साथ वेब पर खोजें जो आपके सामने आता है।

अब हम परीक्षण सूट चलाने के लिए तैयार हैं। यदि आप GNU / Linux, macOS, या यूनिक्स के कुछ अन्य स्वाद का उपयोग कर रहे हैं, तो चलाएं:

$ ./runtests.py
...\> runtests.py 

अब वापस बैठो और आराम करो। Django के पूरे परीक्षण सूट में 9,600 से अधिक विभिन्न परीक्षण हैं, इसलिए आपके कंप्यूटर की गति के आधार पर इसे चलाने में 5 से 15 मिनट तक का समय लग सकता है।

जब Django का परीक्षण सूट चल रहा होता है, तो आपको प्रत्येक परीक्षण की स्थिति का प्रतिनिधित्व करने वाले पात्रों की एक धारा दिखाई देगी, क्योंकि यह चलता है। E इंगित करता है कि एक परीक्षण के दौरान एक त्रुटि हुई थी, और F इंगित करता है कि एक परीक्षण के दावे विफल हो गए। इन दोनों को परीक्षण विफल माना जाता है। इस बीच, x और s ने क्रमशः असफल असफलताओं और स्किप किए गए परीक्षणों का संकेत दिया। डॉट्स पासिंग टेस्ट का संकेत देते हैं।

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

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

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

ध्यान दें

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

अपने पैच के लिए एक शाखा बनाना

कोई भी परिवर्तन करने से पहले, टिकट के लिए एक नई शाखा बनाएँ:

$ git checkout -b ticket_24788
...\> git checkout -b ticket_24788

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

अपने टिकट के लिए कुछ परीक्षण लिखना

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

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

अब हमारे हाथों के उदाहरण के लिए।

टिकट के लिए कुछ परीक्षण लिखना # 24788

टिकट #24788 एक छोटे से फीचर #24788 का प्रस्ताव करता है: फॉर्म क्लास पर क्लास स्तर की विशेषता prefix को निर्दिष्ट करने की क्षमता, ताकि:

[…] forms which ship with apps could effectively namespace themselves such
that N overlapping form fields could be POSTed at once and resolved to the
correct form.

इस टिकट को हल करने के लिए, हम BaseForm वर्ग में एक prefix विशेषता जोड़ देंगे। इस वर्ग के उदाहरण बनाते समय, __init__() विधि के लिए एक उपसर्ग पास करना फिर भी उस उपसर्ग को बनाए गए उदाहरण पर सेट करेगा। लेकिन प्रीफ़िक्स (या None पासिंग) पास None करना क्लास-लेवल प्रीफ़िक्स का उपयोग करेगा। इससे पहले कि हम उन परिवर्तनों को करें, लेकिन हम यह सत्यापित करने के लिए एक दो परीक्षण लिखने जा रहे हैं कि हमारा संशोधन सही ढंग से कार्य करता है और भविष्य में सही ढंग से काम करता है।

Django के tests/forms_tests/tests/ फ़ोल्डर में नेविगेट करें और test_forms.py फ़ाइल खोलें। निम्नलिखित कोड को test_forms_with_null_boolean लाइन पर test_forms_with_null_boolean फ़ंक्शन से पहले जोड़ें:

def test_class_prefix(self):
    # Prefix can be also specified at the class level.
    class Person(Form):
        first_name = CharField()
        prefix = 'foo'

    p = Person()
    self.assertEqual(p.prefix, 'foo')

    p = Person(prefix='bar')
    self.assertEqual(p.prefix, 'bar')

यह नया परीक्षण यह जाँचता है कि एक वर्ग स्तर के उपसर्ग की स्थापना अपेक्षित रूप से काम करती है, और यह कि एक prefix पैरामीटर को पास करते हुए एक उदाहरण बनाते हुए अभी भी काम करता है।

लेकिन इस परीक्षण बात थोड़े कठिन लगता है ...

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

  • Django के लिए लेखन परीक्षण पर एक अच्छा पहला नज़र दस्तावेज लेखन और परीक्षण चलाने पर पाया जा सकता है।
  • पायथॉन में डाइव करें (पायथन डेवलपर्स की शुरुआत के लिए एक नि: शुल्क ऑनलाइन पुस्तक) में यूनिट परीक्षण के लिए एक महान परिचय शामिल है।
  • उन लोगों को पढ़ने के बाद, यदि आप अपने दांतों को सिंक करने के लिए कुछ मांसाहार चाहते हैं, तो हमेशा पायथन unittest प्रलेखन होता है।

अपना नया टेस्ट चला रहे हैं

याद रखें कि हमने वास्तव में BaseForm अभी तक कोई संशोधन नहीं किया है, इसलिए हमारे परीक्षण विफल हो रहे हैं। चलो यह सुनिश्चित करने के लिए कि वास्तव में क्या होता है, forms_tests फ़ोल्डर में सभी परीक्षण चलाते हैं। कमांड लाइन से, Django tests/ निर्देशिका में cd और भागो:

$ ./runtests.py forms_tests
...\> runtests.py forms_tests

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

अपने टिकट के लिए कोड लिखना

अगले हम Django के लिए टिकट #24788 में वर्णित कार्यक्षमता जोड़ देंगे।

टिकट के लिए कोड लिखना # 24788

django/django/forms/ फ़ोल्डर में नेविगेट करें और forms.py फ़ाइल खोलें। लाइन 72 पर BaseForm वर्ग का पता लगाएं और field_order विशेषता के बाद prefix वर्ग विशेषता जोड़ें:

class BaseForm:
    # This is the main implementation of all the Form logic. Note that this
    # class is different than Form. See the comments by the Form class for
    # more information. Any improvements to the form API should be made to
    # *this* class, not to the Form class.
    field_order = None
    prefix = None

अपना परीक्षण सत्यापित करके अब पास हो गया है

एक बार जब आप Django को संशोधित कर रहे होते हैं, तो हमें यह सुनिश्चित करने की आवश्यकता होती है कि हमने पहले लिखे गए टेस्ट पास कर लिए हैं, इसलिए हम देख सकते हैं कि हमने जो कोड ऊपर लिखा है वह सही तरीके से काम कर रहा है या नहीं। forms_tests फ़ोल्डर में परीक्षण चलाने के लिए, Django tests/ निर्देशिका में cd और चलाएँ:

$ ./runtests.py forms_tests
...\> runtests.py forms_tests

उफ़, अच्छी बात है कि हमने उन परीक्षणों को लिखा है! आपको निम्न अपवाद के साथ एक विफलता अभी भी देखनी चाहिए:

AssertionError: None != 'foo'

हम __init__ पद्धति में सशर्त विवरण जोड़ना भूल गए। आगे बढ़ें और self.prefix = prefix बदलें। self.prefix = prefix जो अब django/forms/forms.py की लाइन 87 पर है, सशर्त जोड़ने के लिए:

if prefix is not None:
    self.prefix = prefix

परीक्षणों को फिर से चलाएं और सब कुछ पास होना चाहिए। यदि ऐसा नहीं होता है, तो सुनिश्चित करें कि आपने ऊपर दिखाए गए अनुसार सही तरीके से BaseForm क्लास को संशोधित किया है और नई परीक्षा की प्रतिलिपि बनाई है।

दूसरी बार Django के परीक्षण सूट को चलाना

एक बार जब आप यह सत्यापित कर लेते हैं कि आपका पैच और आपका परीक्षण सही तरीके से काम कर रहे हैं, तो यह पूरी तरह से पूरे Django टेस्ट सूट को चलाने के लिए एक अच्छा विचार है कि आपके परिवर्तन ने Django के अन्य क्षेत्रों में कोई बग पेश नहीं किया है। हालांकि पूरे परीक्षण सूट को सफलतापूर्वक पारित करने की गारंटी नहीं है कि आपका कोड बग मुक्त है, यह कई बग और प्रतिगमन को पहचानने में मदद करता है जो अन्यथा किसी का ध्यान नहीं जा सकते हैं।

पूरे Django परीक्षण सूट को चलाने के लिए, Django tests/ निर्देशिका में cd और चलाएं:

$ ./runtests.py
...\> runtests.py 

जब तक आपको कोई असफलता नहीं दिखती है, आप जाना अच्छा समझते हैं।

लेखन दस्तावेज़

यह एक नई सुविधा है, इसलिए इसे प्रलेखित किया जाना चाहिए। निम्नलिखित अनुभाग को django/docs/ref/forms/api.txt लाइन 1068 (फाइल के अंत में) पर django/docs/ref/forms/api.txt :

The prefix can also be specified on the form class::

    >>> class PersonForm(forms.Form):
    ...     ...
    ...     prefix = 'person'

.. versionadded:: 1.9

    The ability to specify ``prefix`` on the form class was added.

चूंकि यह नई सुविधा एक आगामी रिलीज में होगी, यह Django 1.9 के लिए रिलीज़ नोट्स में भी शामिल है, फ़ाइल docs/releases/1.9.txt में "फ़ॉर्म" अनुभाग के तहत लाइन 164 पर:

* A form prefix can be specified inside a form class, not only when
  instantiating a form. See :ref:`form-prefix` for details.

लेखन दस्तावेज़ीकरण के बारे में अधिक जानकारी के लिए, जो कि versionadded बिट के बारे में है, का एक विवरण सहित, लेखन दस्तावेज़ देखें। उस पृष्ठ में स्थानीय रूप से दस्तावेज़ीकरण की एक प्रतिलिपि बनाने का एक विवरण भी शामिल है, इसलिए आप उत्पन्न होने वाले HTML का पूर्वावलोकन कर सकते हैं।

अपने परिवर्तनों का पूर्वावलोकन करना

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

$ git diff
...\> git diff

ऊपर और नीचे जाने के लिए तीर कुंजियों का उपयोग करें।

diff --git a/django/forms/forms.py b/django/forms/forms.py
index 509709f..d1370de 100644
--- a/django/forms/forms.py
+++ b/django/forms/forms.py
@@ -75,6 +75,7 @@ class BaseForm:
     # information. Any improvements to the form API should be made to *this*
     # class, not to the Form class.
     field_order = None
+    prefix = None

     def __init__(self, data=None, files=None, auto_id='id_%s', prefix=None,
                  initial=None, error_class=ErrorList, label_suffix=None,
@@ -83,7 +84,8 @@ class BaseForm:
         self.data = data or {}
         self.files = files or {}
         self.auto_id = auto_id
-        self.prefix = prefix
+        if prefix is not None:
+            self.prefix = prefix
         self.initial = initial or {}
         self.error_class = error_class
         # Translators: This is the default suffix added to form field labels
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
index 3bc39cd..008170d 100644
--- a/docs/ref/forms/api.txt
+++ b/docs/ref/forms/api.txt
@@ -1065,3 +1065,13 @@ You can put several Django forms inside one ``<form>`` tag. To give each
     >>> print(father.as_ul())
     <li><label for="id_father-first_name">First name:</label> <input type="text" name="father-first_name" id="id_father-first_name"></li>
     <li><label for="id_father-last_name">Last name:</label> <input type="text" name="father-last_name" id="id_father-last_name"></li>
+
+The prefix can also be specified on the form class::
+
+    >>> class PersonForm(forms.Form):
+    ...     ...
+    ...     prefix = 'person'
+
+.. versionadded:: 1.9
+
+    The ability to specify ``prefix`` on the form class was added.
diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt
index 5b58f79..f9bb9de 100644
--- a/docs/releases/1.9.txt
+++ b/docs/releases/1.9.txt
@@ -161,6 +161,9 @@ Forms
   :attr:`~django.forms.Form.field_order` attribute, the ``field_order``
   constructor argument , or the :meth:`~django.forms.Form.order_fields` method.

+* A form prefix can be specified inside a form class, not only when
+  instantiating a form. See :ref:`form-prefix` for details.
+
 Generic Views
 ^^^^^^^^^^^^^

diff --git a/tests/forms_tests/tests/test_forms.py b/tests/forms_tests/tests/test_forms.py
index 690f205..e07fae2 100644
--- a/tests/forms_tests/tests/test_forms.py
+++ b/tests/forms_tests/tests/test_forms.py
@@ -1671,6 +1671,18 @@ class FormsTestCase(SimpleTestCase):
         self.assertEqual(p.cleaned_data['last_name'], 'Lennon')
         self.assertEqual(p.cleaned_data['birthday'], datetime.date(1940, 10, 9))

+    def test_class_prefix(self):
+        # Prefix can be also specified at the class level.
+        class Person(Form):
+            first_name = CharField()
+            prefix = 'foo'
+
+        p = Person()
+        self.assertEqual(p.prefix, 'foo')
+
+        p = Person(prefix='bar')
+        self.assertEqual(p.prefix, 'bar')
+
     def test_forms_with_null_boolean(self):
         # NullBooleanField is a bit of a special case because its presentation (widget)
         # is different than its data. This is handled transparently, though.

जब आप पैच का पूर्वावलोकन कर रहे हों, तो कमांड लाइन पर लौटने के लिए q कुंजी को हिट करें। यदि पैच की सामग्री ठीक दिखती है, तो परिवर्तनों को करने का समय आ गया है।

पैच में बदलाव करना

परिवर्तनों को करने के लिए:

$ git commit -a
...\> git commit -a

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

Fixed #24788 -- Allowed Forms to specify a prefix at the class level.

प्रतिबद्ध को धक्का देना और एक पुल अनुरोध करना

पैच करने के बाद, इसे GitHub पर अपने कांटे पर भेजें (यदि यह अलग है तो अपनी शाखा के नाम के साथ "टिकट_24788" चुनें):

$ git push origin ticket_24788
...\> git push origin ticket_24788

आप Django GitHub पृष्ठ पर जाकर एक पुल अनुरोध बना सकते हैं। आप अपनी शाखा को "आपकी हाल ही में धकेल दी गई शाखाओं" के तहत देखेंगे। इसके बगल में "तुलना और पुल अनुरोध" पर क्लिक करें।

कृपया इसे इस ट्यूटोरियल के लिए न करें, लेकिन अगले पृष्ठ पर जो पैच का पूर्वावलोकन प्रदर्शित करता है, आप "पुल अनुरोध बनाएँ" पर क्लिक करेंगे।

अगला कदम

बधाई हो, आपने सीखा है कि कैसे Django के लिए एक अनुरोध करें! अधिक उन्नत तकनीकों का विवरण जिनकी आपको आवश्यकता हो सकती है Git और GitHub के साथ कार्य करना

अब आप उन स्किल्स को जिंजो के कोडबेस को बेहतर बनाने में मदद कर सकते हैं।

नए योगदानकर्ताओं के लिए अधिक जानकारी

इससे पहले कि आप भी Django के लिए पैच लिखने में शामिल हों, योगदान देने के बारे में थोड़ी और जानकारी है जिसे आपको संभवतः देखना चाहिए:

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

अपना पहला असली टिकट पा रहे हैं

एक बार जब आप उस कुछ जानकारी को देख लेते हैं, तो आप एक पैच लिखने के लिए बाहर जाने और खुद का टिकट खोजने के लिए तैयार होंगे। "आसान उठा" कसौटी के साथ टिकट पर विशेष ध्यान दें। ये टिकट अक्सर प्रकृति में बहुत सरल होते हैं और पहली बार योगदानकर्ताओं के लिए बहुत अच्छे होते हैं। एक बार जब आप Django में योगदान करने से परिचित हो जाते हैं, तो आप अधिक कठिन और जटिल टिकटों के लिए पैच लिखना शुरू कर सकते हैं।

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

पुल अनुरोध बनाने के बाद आगे क्या है?

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