Requests: पायथन 3.5 के मानक पुस्तकालय में अनुरोधों को शामिल करने पर विचार करें

हां, क्योंकि यह पूरी प्रक्रिया को सरल करता है और प्रदर्शन का त्याग नहीं करता है। इसलिए हां।

• अनुरोधों के विकसित होने और बढ़ने की क्षमता पर इसका किस प्रकार का प्रभाव पड़ेगा?
• क्या अनुरोध 'रिलीज आवृत्ति पाइथन के साथ रहती है? यहां एक बड़ा अंतर एक अच्छा संकेत हो सकता है कि अनुरोध के लिए stdlib सही घर नहीं है।

आइए कुछ ऐसे लोगों को CC करें जिनकी राय का हम बहुत ध्यान रखते हैं:

@shazow @kevinburke @dstufft @alex @sigmavirus24

"मानक lib वह जगह है जहां चीजें मर जाती हैं" का क्या हुआ?

रिलीज ताल प्रश्न एक अच्छा है; मैं स्वतंत्र रूप से विकसित होने के अनुरोध की क्षमता को खोने के बारे में चिंतित हूं। उस ने कहा, शायद एक अनुरोध कोर पुस्तकालय एक अच्छा फिट होगा।

मेरी 2 $CURRENCY की कीमत है:

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

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

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

मुझे नहीं लगता कि आप वास्तव में _can_ पहले chardet और urllib3 को जोड़े बिना या उन पर अपनी निर्भरता को हटाए बिना stdlib में अनुरोध जोड़ते हैं। वहाँ भी एक चीज है जहां पायथन एक सीए बंडल को शिप नहीं करना चाहता है, इसलिए आपको इसे संशोधित करने की आवश्यकता होगी ताकि यह सिस्टम प्लेटफॉर्म बंडल का उपयोग करे जैसा कि पायथन अब स्वाभाविक रूप से करता है।

इसके अलावा, मुझे यकीन नहीं है। यह निश्चित रूप से अनुरोध प्राप्त करना आसान बना देगा, हालांकि पाइप पर मेरे काम का हिस्सा मूल रूप से इसे बनाना है, इसलिए इसे stdlib में जोड़ने की आवश्यकता के बिना अनुरोध जैसी चीजें प्राप्त करना आसान है। इसके शीर्ष पर यह कुछ हद तक भ्रमित करने वाला है कि पाइथन stdlib में HTTP अनुरोध करने के कई तरीके हैं। urllib और urllib2 का एकीकरण Python stdlib में एक अच्छी बात थी और मुझे नहीं लगता कि urllib.request और "request" के साथ इसे फिर से जोड़ना एक अच्छा विचार है। अंत में मुझे नहीं लगता कि यह वास्तव में कई लोगों की मदद करेगा, यह केवल 3.5+ में जाएगा, इसलिए जो कोई भी अनुरोधों का उपयोग करना चाहता है उसे या तो उस संस्करण का उपयोग करना होगा जो पीईपीआई पर है या 3.5 को अपना न्यूनतम समर्थित पायथन संस्करण बनाना है जो मैं नहीं करता हूं। टी थिंक किसी भी निकट भविष्य में होने वाली एक यथार्थवादी बात है।

जबकि मुझे लगता है कि मानक पुस्तकालय में अनुरोध होने से नए उपयोगकर्ताओं को मदद मिलेगी, मुझे नहीं पता कि यह पूरी तरह से पायथन समुदाय की मदद करेगा। अनुभवी उपयोगकर्ता अनुरोधों का उपयोग करना जानते हैं और जानते हैं कि इसे कैसे स्थापित किया जाए।

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

डिफ़ॉल्ट रूप से स्थापित पायथन वितरण जहाज बनाने के मध्य मैदान के बारे में क्या?

नहीं यह नहीं होगा।

अनुरोध मेरे सामने बताए गए कई कारणों से stdlib समावेशन के लिए बिल्कुल अनुपयुक्त है। अकेले urllib3 निर्भरता एक पूर्ण शोस्टॉपर है; हम नहीं चाहते कि यह stdlib में मर जाए।

जो _उपयोगी होगा वह है कुछ _basic_ जोड़ना और stdlib के वर्तमान http संसाधनों के शीर्ष पर बनाए गए अनुरोधों के समान जो उपयोगकर्ताओं को रक्त जादू का अभ्यास किए बिना https को सरल प्राप्त/पोस्ट अनुरोध करने की अनुमति देता है।

यह भी याद दिलाएं कि इसे केवल पायथन 3 में जोड़ा जाएगा। :) (और पायथन 3.6 से पहले नहीं)।

क्या आप इसे केनेथ बनाए रखने से थक रहे हैं? ;)

मुझे नहीं लगता कि हम इस प्रश्न पर चर्चा शुरू कर सकते हैं बिना किसी को बताए कि httplib, urllib, और दोस्तों का क्या होता है। पसंद की जटिलता को संबोधित किए बिना अनुरोध जोड़ना, मुझे लगता है, उत्तर से भी बदतर है "तह stdlib को अनदेखा करें, बस अनुरोधों का उपयोग करें"। यह urllib, urllib2 के दिनों का प्रतिगमन है।

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

मैं मदद करने की कोशिश करने के लिए stdlib में घूमूंगा, लेकिन इस तथ्य को देखते हुए कि वास्तव में मुझे नहीं पता कि मैंने कितने पिछले पैचसेट जमा किए हैं और एक अन्य _reviewed_ मुझे उस प्रक्रिया से परेशान होने से सावधान करता है। मुझे पता है कि मुख्य देव पूरी तरह से अधिक महत्वपूर्ण चीजों से घिरे हुए हैं। मुझे यह भी पता है कि किसी और ने बेतरतीब ढंग से फैसला किया है कि वे httplib/http को बनाए रखना चाहते हैं लेकिन वे स्पष्ट रूप से नौकरी के लिए उपयुक्त नहीं हैं (अभी तक) और मेरे पास httplib पर काम करने का धैर्य नहीं है जब पैच @ लुकासा और मैं दोनों बैठते हैं चारों ओर, बिना समीक्षा की, और इसकी परवाह नहीं की (जब वे पुस्तकालय के साथ समस्याओं को ठीक करते हैं)।

मैं शायद इसका उपयोग जारी रखने के लिए केवल फोर्किंग अनुरोधों को समाप्त कर दूंगा।

अनुरोध मेरे सामने बताए गए कई कारणों से stdlib समावेशन के लिए बिल्कुल अनुपयुक्त है। अकेले urllib3 निर्भरता एक पूर्ण शोस्टॉपर है; हम नहीं चाहते कि यह stdlib में मर जाए।

यह हमेशा @kennethreitz (और इसलिए, पूरी तरह से परियोजना) का विवाद रहा है कि urllib3 एक कार्यान्वयन विवरण है। कई अनुरोधों की सबसे बड़ी विशेषताएं पूरी तरह से urllib3 द्वारा नियंत्रित की जाती हैं, लेकिन इसका मतलब यह नहीं है कि उन्हें वास्तव में निर्भरता-कम पुस्तकालय में देखभाल के साथ पुन: कार्यान्वित नहीं किया जा सकता है।

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

इस बारे में कि हमें यह करना चाहिए या नहीं, मैं स्पष्ट रूप से असंबद्ध हूं। जो कुछ भी stdlib में होगा वह केवल API में अनुरोध होगा। पायथन 3 गोद लेने की दर इतनी धीमी है कि मुझे नहीं लगता कि अगले एन वर्षों के लिए लोग इससे सार्थक रूप से प्रभावित होंगे (जहां एन वैश्विक स्तर पर अज्ञात संख्या है 3.5 के लिए निगमों द्वारा उत्पादन में उपयोग किया जाना है)।

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

मैंने दूसरे दिन गुइडो के साथ इस पर विस्तार से चर्चा की - पहले चारडेट को शामिल करना होगा। मुझे लगता है कि urllib3 और अनुरोधों को एक साथ http पैकेज में शामिल किया जा सकता है।

हालांकि, मैं @hynek और @dstufft से सहमत होने के इच्छुक हूं। शायद अनुरोध ठीक वैसे ही ठीक है :)

किसी भी तरह से, यदि आपकी कोई राय है जिसे आप साझा करना चाहते हैं, तो इसे यहां (या वास्तव में कभी भी) साझा करने के लिए आपका स्वागत है।

:चमक: :केक: :चमक:

साथ ही, बिना किसी एसिंक्सियो-स्टोरी के stdlib में एक नया http मॉड्यूल जोड़ना लगता है
मेरे लिए बोनकर्स।

सन 25 जनवरी 2015 को दोपहर 1:15:51 बजे केनेथ रीट्ज़ नोटिफिकेशन @github.com
लिखा था:

किसी भी तरह, अगर आपकी कोई राय है जिसे आप साझा करना चाहते हैं, तो आप हैं
इसे यहां साझा करने के लिए आपका स्वागत है (या वास्तव में कभी भी)।

[छवि:: चमक:] [छवि::केक:] [छवि::चमक:]

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

मुझे नहीं लगता कि हम इस प्रश्न पर चर्चा करना शुरू कर सकते हैं बिना किसी को बताए कि httplib, urllib, और दोस्तों का क्या होता है

यह मेरा मुद्दा है। मुझे लगता है कि मौजूदा भ्रमित करने वाली स्थिति को पहले सुलझाना होगा।

:+1: :धातु:

बस स्पष्ट होने के लिए, stdlib में शामिल करने के लिए urllib3 को फिर से लागू करने के बारे में मेरी उपरोक्त टिप्पणी को हल्के में नहीं लिया जाना चाहिए। ऐसा करने के लिए आवश्यक कार्य की मात्रा बहुत अधिक होगी क्योंकि urllib3 डेवलपर कार्य के (संभावित 10 या अधिक) वर्षों का उत्पाद है।

मैंने भी कुछ साल पहले urllib3 को stdlib में उछालने के बारे में गुइडो के साथ बात की थी, इस निष्कर्ष के साथ कि यह एक अच्छा विचार नहीं है, लेकिन मैं इस समय इसके बारे में काफी तटस्थ हूं।

urllib3 का एपीआई कई वर्षों से अधिकतर स्थिर और काफी पीछे की ओर संगत रहा है। इसकी गति संभवतः आज के stdlib की तुलना में भी धीमी है, जिसमें अधिकांश परिवर्तन मामूली सुधार या सुरक्षा सुधार हैं (कभी-कभी पीछे की ओर-संगत सुविधा परिवर्धन जैसे दानेदार टाइमआउट/पुनः प्रयास के साथ)। अगर कोई वास्तव में मानक पुस्तकालय में urllib3 प्राप्त करने का प्रयास करना चाहता है, तो मुझे नहीं लगता कि यह एक भयानक विचार है-यह सिर्फ _best_ विचार नहीं है।

(मैं अनुरोधों के लिए नहीं बोल रहा हूं, क्योंकि यह urllib3 की तुलना में विभिन्न लक्ष्यों के साथ बहुत अलग गति से चलता है।)

सबसे अच्छा विचार, मेरी राय में, पीएसएफ के लिए 1-3 डेवलपर्स को किराए पर लेना होगा (या शायद किकस्टार्ट या कुछ और) urllib3 से भारी प्रेरणा के साथ HTTP / 2 समर्थन के साथ asyncio के शीर्ष पर एक नया http पुस्तकालय बनाने के लिए, अनुरोध , और हाइपर। मुझे जितना संभव हो उतना शब्दशः लिया गया कोड देखकर खुशी होगी, लेकिन एक सुसंगत, मॉड्यूलर और पुन: प्रयोज्य तरीके से निर्धारित किया गया। आदर्श रूप से पायथन 4 या कुछ को लक्षित करें, और सभी urllibs और httplibs से छुटकारा पाएं। मुझे उम्मीद है कि यह कड़ी मेहनत का 6-9mo होगा, लेकिन संभवतः अधिक।

urllib3 के बारे में सबसे खराब हिस्सा, जिसे मैं बदलना पसंद करूंगा यदि कोई इसे @ sigmavirus24 के सुझाव के अनुसार फिर से लिखने का प्रयास करता है, तो यह httplib पर निर्भर करता है। urllib3 की कार्यक्षमता काफी हद तक httplib की कमियों के आसपास काम करने में खर्च किए गए बहुत सारे कोड के साथ सीमित है। यद्यपि यदि इस लक्ष्य में HTTP/2 समर्थन को गंभीरता से लिया जाएगा, तो HTTP/1.1 को फिर से लागू करने का दायरा आवश्यक कार्य का एक बहुत ही आरामदायक अंश होगा।

कई PyCons पहले, हम में से एक ने मुलाकात की और एक बिल्कुल नई http लाइब्रेरी के एक लेआउट को व्हाइटबोर्ड किया, जो उस समय की कल्पना की गई आदर्श व्यवस्था में सभी टुकड़ों को रिफैक्टर करता है। अगर कोई इसे आजमाने जा रहा है तो मुझे इन नोटों को खोदने में खुशी होगी।

+1 @shazow

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

हां क्योंकि एक ही तरीका है कि मैं कभी भी एक निर्भरता के रूप में अनुरोधों की अनुमति दूंगा यदि यह stdlib में है।

उस ने कहा, urllib3 में वे विशेषताएं हैं जो लोग वास्तव में चाहते हैं, इसलिए stdlib में होना मेरे लिए पर्याप्त है

क्या आप किसी निर्भरता का उपयोग नहीं करते हैं?

@dstufft यह उन परियोजनाओं में है जो आम तौर पर नहीं होती हैं, जहां हर किसी को urllib का उपयोग करने का तरीका जानने के लिए परेशान नहीं किया जा सकता है। (आमतौर पर लोग इसे एसएसएल/आदि के कारण एक प्रतिनिधि के रूप में नहीं जोड़ रहे हैं, लेकिन आलस्य से बाहर)

@dstufft भी बहु-संस्करण

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

@ सिग्मावायरस 24 मैं असहमत हूं। अनुरोधों का एपीआई परिवर्तन अतीत में हुआ है। एपीआई बदलते हैं, इसलिए हमारे पास वर्जनिंग है, इसलिए निर्भरताएं जटिल हैं। यह उस चर्चा के लिए एक आदर्श मामला है क्योंकि अनुरोध कई परियोजनाओं में निर्भरता है।

यदि आप stdlib में जाते हैं तो API स्थिर होना चाहिए।

@dcramer एपीआई 1.0 में ठीक एक बार टूट गया। एपीआई बदलते हैं, लेकिन अनुरोध 'एपीआई किसी भी बदलाव की योजना नहीं बना रहा है। हमने जो एकमात्र बदलाव किया है वह json पैरामीटर जोड़ रहा है जो कुछ भी नहीं तोड़ता है। आप हम पर एपीआई को तोड़ने का आरोप लगाने की कोशिश कर सकते हैं, लेकिन जब ओपनस्टैक जैसी परियोजनाओं में लंबे समय तक >=1.2.3 रूप में परिभाषित आवश्यकताएं होती हैं, तो मुझे लगता है कि अनुरोधों की स्थिरता के बारे में बहुत कुछ कहता है। एपीआई स्थिर रहा है, ठीक है क्योंकि 1.0 में कटौती के बाद हमने एपीआई में सभी नए परिवर्धन को अस्वीकार कर दिया है ( json परम जोड़ने के स्पष्ट हालिया अपवाद के साथ) और हम एपीआई को नहीं तोड़ने के बारे में बहुत सख्त हैं। यदि आप अनुरोधों के उपभोक्ता नहीं हैं, तो आपको यह नहीं पता होगा। इसलिए मैं आपकी अज्ञानता को व्यक्तिगत रूप से नहीं लेता।

इसके अलावा अगर stdlib API को इतना स्थिर माना जाता है, तो समझाएं कि क्यों argparse ने Python 3.3 और 3.4 के बीच सार्वजनिक API को तोड़ा?

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

आप जानते हैं कि पायथन अपने एपीआई को भी बदलता है, अक्सर वास्तव में, कभी-कभी बहुत प्रमुख तरीकों से, शायद आपने पायथन 3 के बारे में सुना है?

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

मुझे लगता है कि उत्तर देने के लिए कुछ महत्वपूर्ण प्रश्न हैं:

1. आप मानक दस्तावेज़ीकरण (ट्यूटोरियल सहित) को कैसे बदलना चाहेंगे? वर्तमान मानक पुस्तकालय HTTP एपीआई एक ऐसे युग से दिनांकित है जहां प्रतिस्पर्धी प्रोटोकॉल (जैसे एफ़टीपी बनाम एचटीटीपी) के विवरण को दूर करना एक वांछनीय दृष्टिकोण माना जाता था। बाद के डेढ़ दशक में, वेब डेवलपमेंट कम्युनिटी ने HTTPS+JSON को रिमोट कमांड निष्पादन (जो SSH या Windows RCP का उपयोग करता है) के अलावा अधिकांश उपयोग के मामलों के लिए अनुरोध/प्रतिक्रिया शैली क्लाइंट/सर्वर इंटरैक्शन के लिए पसंदीदा दृष्टिकोण के रूप में परिवर्तित किया है। और अनुरोध एपीआई आधुनिक पायथन अनुप्रयोगों के लिए उस मॉडल का वास्तविक मानक क्लाइंट कार्यान्वयन है।
2. क्या आप चाहते हैं कि अनुरोध API को वास्तविक मानक से एक कानूनी मानक में अपग्रेड किया जाए, जैसे कि यह स्वचालित रूप से सभी CPython पुनर्वितरण चैनलों में शामिल हो जाता है, CPython (और हमारे वाणिज्यिक पुनर्वितरणकर्ताओं) द्वारा दीर्घकालिक समर्थन गारंटी के साथ-साथ समर्थित हो जाता है। सभी "केवल मानक पुस्तकालय" शैक्षिक गतिविधियाँ? (उत्तरार्द्ध अभी भी बहुत आम हैं, क्योंकि कॉर्पोरेट वातावरण में उपयोग के मानदंड में अक्सर समर्थन और आईपी गारंटी शामिल होती है, जो सीपीथॉन के पास होती है, लेकिन अनुरोध नहीं करता है। वर्तमान स्थिति के तहत, कई उपयोगकर्ता केवल अनुरोधों को एक विकल्प के रूप में नहीं मानेंगे क्योंकि इसे उपयोग के लिए मान्यता प्राप्त करना उनके लिए बहुत अधिक काम है)
3. एपीआई जैसे अनुरोधों को बनाने के लिए मानक पुस्तकालय में अन्य कौन से मॉड्यूल में सुधार किया जा सकता है?
4. क्या एपीआई के संस्करण-स्वतंत्र कार्यान्वयन के रूप में अनुरोधों को अपरिवर्तित रखना बेहतर होगा, और इसके बजाय मानक पुस्तकालय में एक नया अनुरोध प्रेरित एपीआई जोड़ें, जिस तरह से गुइडो ने एयनियो मानकीकरण कार्य से संपर्क किया था?

जहां तक ​​पीएसएफ प्रबंधित विकास कार्य के विचार की बात है, तो मैं इसके सख्त खिलाफ रहूंगा, क्योंकि हमारे पास इस तरह की चीजों को संभालने के लिए प्रबंधन का बुनियादी ढांचा नहीं है। इस क्षेत्र में एक क्राउडफंडेड प्रयास में पीएसएफ के योगदान का सुझाव देने वाला एक अनुदान प्रस्ताव एक अलग कहानी होगी (समीक्षा के लिए एक विशिष्ट प्रस्ताव के बिना कोई गारंटी नहीं है, लेकिन यह निश्चित रूप से एक विचार है जिस पर हम चर्चा कर सकते हैं)।

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

मानक पुस्तकालय के साथ, हमें आम तौर पर वह चिंता नहीं होती है - जबकि पुनर्वितरणकर्ता कभी-कभी चीजों को तोड़ देते हैं, एक वाणिज्यिक संदर्भ में, विक्रेता जो सामान तोड़ते हैं, जो अपस्ट्रीम में काम करता है, आपको आपत्तिजनक विक्रेता को चीजों को ठीक करने के लिए काफी लाभ देता है।

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

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

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

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

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

"ओपन सोर्स कम्युनिटी" फिल्टर बबल कैसे हमारे दृष्टिकोण को तिरछा कर सकता है, इसके अधिक ठोस उदाहरण के रूप में: जेनकिंस के पास कॉर्पोरेट सीआई परिनियोजन में 70% से अधिक बाजार हिस्सेदारी है।

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

@dcramer
सुनिश्चित नहीं है कि आप किस बारे में कुतिया कर रहे हैं।

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

@ncoghlan

पुन: बिंदु १: मुझे लगता है कि प्रलेखन को stdlib में अनुरोधों (अनुरोधों-समान) के साथ काफी सरल बनाया जाएगा। एक नई भाषा सीखते समय मैं सबसे पहले यह पता लगाता हूं कि HTTP कैसे काम करता है। उस विशेषता का होना कुछ ऐसा है जिससे गाइड को लाभ होगा।

पुन: बिंदु 2: एपीआई और पुस्तकालय के बीच वास्तविक बनाम कानूनी रूप से अंतर है। एपीआई आसानी से मानक पुस्तकालय द्वारा प्रदान किया जा सकता है। मुझे लगता है कि समर्थन के बारे में आपकी चिंता अनुरोधों (कोड) को शामिल करने के लिए अधिक लक्षित होगी।

पुन अंक ३ और ४: मुझे यकीन नहीं है कि यहाँ कुछ चर्चा की जानी है। शायद अजगर-विचार बेहतर होंगे।

जहां तक ​​पीएसएफ प्रबंधित विकास कार्य के विचार की बात है, तो मैं इसके सख्त खिलाफ रहूंगा, क्योंकि हमारे पास इस तरह की चीजों को संभालने के लिए प्रबंधन का बुनियादी ढांचा नहीं है।

यह तो दिलचस्प है। मुझे नहीं लगता था कि यह एक संभावना थी लेकिन http (lib) से कुछ बेहतर होना बहुत अच्छा होगा।

मानक पुस्तकालय के साथ, हमें आम तौर पर वह चिंता नहीं होती है - जबकि पुनर्वितरणकर्ता कभी-कभी चीजों को तोड़ देते हैं, एक वाणिज्यिक संदर्भ में, विक्रेता जो सामान तोड़ते हैं, जो अपस्ट्रीम में काम करता है, आपको आपत्तिजनक विक्रेता को चीजों को ठीक करने के लिए काफी लाभ देता है।

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

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

जैसा कि पहले ही उल्लेख किया गया है, वर्तमान में शामिल अधिकांश लोग परियोजना के साथ जारी नहीं रखेंगे। मैं शायद अकेला व्यक्ति होता लेकिन अपस्ट्रीम सीपीथॉन विकास के साथ अपना ट्रैक रिकॉर्ड दिया, यह उस बोझ को मौजूदा (और अन्य भविष्य) कोर डेवलपर्स पर छोड़कर उत्पादक नहीं होगा।

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

वास्तविकता यह है कि वे लोग कभी नहीं पकड़ेंगे, नहीं? लोग अभी भी Python 2.4 और 2.5 पर सॉफ्टवेयर चला रहे हैं। F5 के लोड बैलेंसर अभी भी केवल पायथन 2.5 का समर्थन करते हैं। 2.7 शायद मेरे प्राकृतिक जीवन के अंत तक उपयोग में रहेगा (जो मुझे आशा है कि यह काफी लंबा होगा)। क्या वाकई ये लोग हैं जो इस फैसले से सबसे ज्यादा प्रभावित होंगे? वही लोग जिनका आप वर्णन करते हैं, वे कभी भी Python 3 में छलांग नहीं लगा सकते हैं। और वर्तमान में, यह अभी भी एक _leap_ है। हो सकता है कि जब तक उन्होंने इस पर विचार करने का फैसला किया, तब तक पायथन 3.8 या 3.9 या 4.2 बाहर हो जाएगा और उनके लिए परेशानी से बहुत कम होगा।

ठीक है, मेरा मुख्य बिंदु यह है कि मानक पुस्तकालय समावेशन का उद्देश्य अन्य ओपन सोर्स डेवलपर्स द्वारा उपयोग के लिए एक ओपन सोर्स लाइब्रेरी प्रदान करने के अधिक सामान्य कार्य से अलग है। यदि अनुरोध टीम केवल स्वतंत्र रूप से अनुरक्षित पुस्तकालय प्रदान करना जारी रखना चुनती है (एक सामुदायिक सेवा जिसके लिए मैं बहुत आभारी हूं, आप लोग बहुत अच्छा काम करते हैं!), और एपीआई के मानकीकरण के लिए एक धक्का नहीं देते हैं, तो हम भरोसा करेंगे आरएचईएल/फेडोरा/सेंटोस, डेबियन/उबंटू, एक्टिवस्टेट, एनथॉट और कॉन्टिनम एनालिटिक्स जैसे पुनर्वितरणकर्ताओं पर मॉड्यूल लेने और इसे _anyway_ पर मानकीकृत करने के लिए, जैसे कि लोग मान सकते हैं कि यह हमेशा उपलब्ध रहेगा (या कम से कम अक्सर उनके लिए पर्याप्त होगा) एकल फ़ाइल स्क्रिप्ट में एपीआई पर भरोसा करते हुए खुश हैं जो उपयुक्त निर्भरता घोषणाओं के साथ पूरी तरह से पैक नहीं हैं)। हालांकि, अधिकांश परिचयात्मक दस्तावेज अभी भी लोगों को HTTP को मानक पुस्तकालय तरीके से करने की दिशा में आगे बढ़ाएंगे, इसलिए लोगों को "पायथन के लिए HTTP, 2001 संस्करण" या "पायथन के लिए HTTP, 2015 संस्करण" पढ़ाया जाता है या नहीं, यह इस बात पर निर्भर करेगा कि वे इसे एक से उठाते हैं या नहीं। "केवल मानक पुस्तकालय" स्रोत, या एक जिसमें अनुशंसित तृतीय पक्ष मॉड्यूल शामिल हैं।

वर्चुअलएन्व और पीईपी 405 के साथ, या ट्विस्टेड + टॉर्नेडो बनाम एसिंकियो, या आईपैड्र बनाम आईपैड्रेस के साथ, मुझे विश्वास नहीं है कि मानक पुस्तकालय में _requests स्वयं_ को शामिल करना समझ में आता है। इसके बजाय, मुझे लगता है कि यह एक अनुरोध _induced_ API को शामिल करने के लिए अधिक समझ में आता है जो सभी क्रॉस संस्करण संगतता कोड, प्रमाणपत्र बंडलिंग इत्यादि को छोड़ देता है, और 2015 तक प्रमाणित HTTP अनुरोधों को संभालने के लिए बस डिफ़ॉल्ट API और दस्तावेज़ लाता है। मानक। फिर २०३० में, हम इस बारे में शिकायत करेंगे कि _requests_ एपीआई डिज़ाइन २०३० मानकों ("HTTP? कौन अब इसका उपयोग करता है?!?!") के बारे में है, लेकिन यह ठीक है, यह ठीक है कि ये चक्र कैसे काम करते हैं (पहले AJAX तक) और फिर JSON साथ आया, XML-RPC पहाड़ी का राजा था)। अगर आपको एपीआई डिज़ाइन से 5 साल पहले मिलते हैं, इससे पहले कि लोग इसके दिनांकित होने के बारे में शिकायत करना शुरू कर दें, तो आप बहुत अच्छा कर रहे हैं, 10 प्रभावशाली है, और 15 वास्तव में शानदार है।

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

कुछ अन्य बिंदुओं के संबंध में, डेबियन के साथ वर्तमान उत्तोलन अपेक्षाकृत कमजोर है, जबकि व्यावसायिक रूप से समर्थित पुनर्वितरण के साथ उत्तोलन बेहतर है, जहां भुगतान करने वाले ग्राहक हमारे द्वारा अपस्ट्रीम विकास समुदाय के रूप में निर्धारित अपेक्षाओं के सापेक्ष चीजों के टूटने के बारे में सीधे शिकायत करने में सक्षम हैं।

अद्यतन चक्रों के संदर्भ में, प्रमुख चीजों में से एक अपस्ट्रीम मानकीकरण (यहां तक ​​​​कि पायथन 3 में भी) से पता चलता है कि सामुदायिक सहमति है। उस पर, पुस्तकालय जो पायथन 3 सुविधाओं के "बैकपोर्ट" हैं, पायथन 2 के साथ बंडलिंग को सही ठहराने के लिए बहुत आसान हो जाते हैं। मैं व्यक्तिगत रूप से अभी भी पाइथन 2 की एक सूमो रिलीज देखना चाहता हूं जो वास्तव में बंडलिंग करता है (unittest2, subprocess32, enum34, contexlib2 , ट्रोलियस, आदि), लेकिन यह अपने आप में एक पूरी तरह से अलग राजनीतिक लड़ाई है, विशेष रूप से लोगों को यह समझाने के मामले में कि 2020 तक इस तरह के पुनर्वितरण स्वतंत्र सूमो वितरण को बनाए रखने के लिए रुचि और संसाधन वास्तव में उपलब्ध हैं।

@dcramer हमें अपना समय देने के लिए धन्यवाद - यह वास्तव में सराहनीय है: दिल:

@ sigmavirus24 सब ठीक है :)

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

चूंकि यह वास्तविक धागा बन सकता है, जब लोग कहते हैं कि लोग इसे देखते हैं
"Stdlib में अनुरोध जोड़ने पर विचार करते समय हमें क्या जोड़ना/बदलना चाहिए",
मैं अपवाद पदानुक्रम को अद्यतन करने के लिए एक और चिल्लाना देना चाहता हूं। मैं
अनुरोध के विफल होने पर आमतौर पर दो प्रश्न होते हैं - क) वे क्या हैं?
आशय? और बी) क्या मैं अनुरोध को सुरक्षित रूप से पुनः प्रयास कर सकता हूं?
एक DNS लुकअप विफलता और एक टूटी हुई पाइप के बहुत अलग निहितार्थ हैं,
लेकिन अनुरोध वर्तमान में दोनों को कनेक्शन त्रुटि के रूप में समूहित करता है। मैंने कुछ विस्तृत किया है
यहां शामिल कार्यों की:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

रुचि रखने वाले लोगों के साथ अधिक चर्चा करने में खुशी हुई।

केविन बर्क
फोन: 925.271.7005 | ट्वेंटीमिलीसेकंड्स.कॉम

सूर्य, 25 जनवरी, 2015 में 8:15 बजे पर, ncoghlan [email protected] लिखा है:

कैसे "ओपन सोर्स कम्युनिटी" फ़िल्टर के अधिक ठोस उदाहरण के रूप में
बुलबुला हमारे दृष्टिकोण को तिरछा कर सकता है: जेनकिंस के पास 70% से अधिक बाजार हिस्सेदारी है
कॉर्पोरेट सीआई परिनियोजन में।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि http://docs.python-requests.org/en/latest/dev/philosophy/ पर

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

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