Requests: असम्पीडित सामग्री को फ़ाइल जैसी वस्तु के रूप में पढ़ने का कोई तरीका नहीं है

Response.iter_content

एर्म, नहीं, यह एक पुनरावर्तक है। मैं एक फ़ाइल जैसी वस्तु के लिए पूछ रहा था, यानी कुछ ऐसा जो दस्तावेज़ प्रोसेसर सीधे पढ़ सकता है।

iter_content साथ फ़ाइल जैसी वस्तु बनाना बहुत आसान होगा

त्वरित उत्तर के लिए धन्यवाद, बीटीडब्ल्यू।

मैं सहमत हूँ। फिर भी, requests के लिए यह कार्यक्षमता प्रदान करना और भी आसान होगा। मेरा कहना है कि .raw अधिकांश उपयोग के मामलों के लिए अमूर्तता का गलत स्तर है जो स्ट्रीम से पढ़ना चाहते हैं, क्योंकि यह स्थानांतरण स्तर के विवरण को उजागर करता है।

व्यक्तिगत रूप से, मुझे HTTP अनुरोध के परिणाम पर लाइन द्वारा लाइन या यहां तक ​​​​कि चंक द्वारा पुनरावृति के लिए एक प्रमुख उपयोग का मामला नहीं दिखता है, लेकिन मुझे फ़ाइल जैसी वस्तु के रूप में इसे पार्स करने के लिए कई प्रमुख उपयोग के मामले दिखाई देते हैं, विशेष रूप से प्रतिक्रिया प्रारूप जिसके लिए एक दस्तावेज़ पार्सर की आवश्यकता होती है, जैसे HTML, XML, Json आदि।

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

मैं निम्नलिखित कोड के साथ आया था। यह सभी आवश्यक मामलों को संभालता है, लेकिन मुझे यह जटिल लगता है। इसलिए मैंने कहा कि मुझे पुस्तकालय के हिस्से के रूप में ऐसा कुछ चाहिए था। उपयोगकर्ताओं को इसे स्वयं नहीं समझना चाहिए।

मुझे लगता है कि अनुरोधों के अंदर कोड 'models.py' यहां गलत अमूर्तता का उपयोग करता है। इसे अपनी पुनरावृति मशीनरी से शुरू होने से पहले कच्ची धारा को विघटित करना चाहिए, न कि पुनरावृत्ति के दौरान। एक फ़ाइल की तरह से एक पुनरावर्तक के लिए बस एक फ़ाइल की तरह वापस जाने के लिए बस सादा बेवकूफी है। एक एकल एपीआई परिवर्तन पर्याप्त से अधिक है और अधिकांश उपयोगकर्ता वैसे भी सामग्री पुनरावृत्तियों की परवाह नहीं करेंगे।

class FileLikeDecompressor(object):
    """
    File-like object that wraps and decompresses an HTTP stream transparently.
    """
    def __init__(self, stream, mode='gzip'):
        self.stream = stream
        zlib_mode = 16 + zlib.MAX_WBITS if mode == 'gzip' else -zlib.MAX_WBITS  # magic
        self.dec = zlib.decompressobj(zlib_mode)
        self.data = ''

    def read(self, n=None):
        if self.dec is None:
            return '' # all done
        if n is None:
            data = self.data + self.dec.decompress(self.stream.read())
            self.data = self.dec = None
            return data
        while len(self.data) < n:
            new_data = self.stream.read(n)
            self.data += self.dec.decompress(new_data)
            if not new_data:
                self.dec = None
                break
        if self.data:
            data, self.data = self.data[:n], self.data[n:]
            return data
        return ''

def decompressed(response):
    """
    Return a file-like object that represents the uncompressed HTTP response data.
    For compressed HTTP responses, wraps the stream in a FileLikeDecompressor.
    """
    stream = response.raw
    mode = response.headers.get('content-encoding')
    if mode in ('gzip', 'deflate'):
        return FileLikeDecompressor(stream, mode)
    return stream

आप प्रस्तावित के रूप में content_iter से फ़ाइल जैसी वस्तु का निर्माण क्यों नहीं करते। यह ऐसा दिख सकता है:

class FileLikeFromIter(object):
    def __init__(self, content_iter):
        self.iter = content_iter
        self.data = ''

    def __iter__(self):
        return self.iter

    def read(self, n=None):
        if n is None:
            return self.data + '\n'.join(l for l in self.iter)
        else:
            while len(self.data) < n:
                try:
                    self.data = '\n'.join((self.data, self.iter.next()))
                except StopIteration:
                    break
            result, self.data = self.data[:n], self.data[n:]
            return result

आप मेरी टिप्पणी फिर से पढ़ना चाह सकते हैं, विशेष रूप से वह पैराग्राफ जो मेरे द्वारा पोस्ट किए गए कोड से पहले है।

हां, लेकिन यह समाधान दूसरे स्थान पर डीकंप्रेसन करने की तुलना में अभी भी क्लीनर (और आईएमओ आसान) है क्योंकि यह पहले से ही अंतर्निहित अनुरोधों में है।

लेकिन मैं सामान्य रूप से आपसे सहमत हूं, r.file (या ऐसा कुछ) में r.raw तुलना में बहुत अधिक उपयोग के मामले हैं। इसलिए मैं इसे अनुरोधों में भी शामिल देखना चाहता हूं। @kennethreitz

"response.stream" मेरे लिए एक अच्छा नाम लगता है।

यही प्रतिक्रिया है। रॉ के लिए है :)

जब मैंने इसे देखा तो मैंने भी सहज रूप से यही सोचा था। लेकिन तब मुझे एहसास हुआ कि response.raw टूटा हुआ है क्योंकि यह अंतर्निहित परिवहन परत के आंतरिक विवरण को उजागर करता है जिसकी उपयोगकर्ताओं को परवाह नहीं करनी चाहिए।

उन्हें केवल raw.read आवश्यकता होनी चाहिए?

ठीक है, हाँ - सिवाय इसके कि raw.read() क्लाइंट और सर्वर के बीच आंतरिक वार्ता के आधार पर अलग-अलग व्यवहार करता है। यह कभी-कभी अपेक्षित डेटा देता है और कभी-कभी यह नंगे संपीड़ित बाइट्स देता है।

मूल रूप से, response.raw एक अच्छी सुविधा है जिसे अधिकांश उपयोगकर्ता खुशी से अनदेखा कर देंगे और कुछ पावर-उपयोगकर्ता मददगार पा सकते हैं, जबकि एक संपीड़न-स्वतंत्र response.stream एक ऐसी सुविधा है जो अधिकांश स्ट्रीमिंग उपयोगकर्ता करेंगे चाहते हैं।

+1

+1

क्या यह डिज़ाइन बग ठीक होने वाला है?

सुनिश्चित नहीं है कि यह तरीका कितना सही या कुशल है, लेकिन मेरे लिए, निम्नलिखित कार्य करता है :

>>> import lxml  # a parser that scorns encoding
>>> unicode_response_string = response.text
>>> lxml.etree.XML(bytes(bytearray(unicode_response_string, encoding='utf-8')))  # provided unicode() means utf-8
<Element html at 0x105364870>

@kernc : ऐसा करना एक विचित्र बात है। response.content पहले से ही एक बाइटस्ट्रिंग है, इसलिए आप यहां जो कुछ भी कर रहे हैं वह सामग्री को डिकोड कर रहा है जो कि नरक कोडेक पायथन चुनता है, फिर इसे utf-8 के रूप में फिर से एन्कोडिंग करता है।

यह _not_ एक बग है, और यह निश्चित रूप से आपके द्वारा सुझाई गई बग नहीं है। यदि आपको वास्तव में फ़ाइल जैसी वस्तु की आवश्यकता है, तो मैं StringIO और BytesIO की अनुशंसा करता हूं।

@ लुकासा सही है। content हमेशा एक बाइटस्ट्रिंग होना चाहिए (पायथन 3 में यह एक स्पष्ट बाइटस्ट्रिंग है; पायथन 2 str == बाइट्स में)। एकमात्र आइटम जो बाइटस्ट्रिंग नहीं है text ।

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

यह कोई डिज़ाइन बग नहीं है, यह केवल एक सुविधा अनुरोध है। और चूंकि अनुरोधों में एक फीचर फ्रीज है, मुझे लगता है कि यह इसे जल्द ही अनुरोधों में नहीं बनाएगा (यदि बिल्कुल भी) ...

मुझे नहीं लगता कि लंबे समय से चली आ रही डिज़ाइन बग को "लापता सुविधा"
यह सब आसानी से दूर कर देता है। मैंने सुना है कि लेखक सोच रहा है
पायथन stdlib का "अनुरोध" हिस्सा बनाना। यह अच्छा होगा
इसे ठीक करने का अवसर।

मैंने सुना है कि लेखक सोच रहा है
पायथन stdlib का "अनुरोध" हिस्सा बनाना।

वास्तव में नहीं: http://docs.python-requests.org/en/latest/dev/philosophy/#standard -लाइब्रेरी

यह एक बग नहीं है, यह एक सुविधा अनुरोध है। अनुरोध कुछ भी गलत नहीं कर रहा है, यह केवल कुछ ऐसा नहीं कर रहा है जो वैकल्पिक है। यह एक विशेषता की बहुत परिभाषा है।

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

मार्क श्लाइच, 19.03.2013 08:41:

मैंने सुना है कि लेखक सोच रहा है
पायथन stdlib का "अनुरोध" हिस्सा बनाना।

वास्तव में नहीं: http://docs.python-requests.org/en/latest/dev/philosophy/#standard -लाइब्रेरी

मैंने इसे यहां पढ़ा:

http://python-notes.boredomandlaziness.org/hi/latest/conferences/pyconus2013/20130313-language-summit.html

स्टीफन

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

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

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

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

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

इस मामले में, अनुरोध मानता है कि अधिकांश उपयोगकर्ता फ़ाइल जैसी वस्तुओं को नहीं चाहते हैं, और इसलिए निम्नलिखित इंटरैक्शन का प्रस्ताव करते हैं:

• Response.text और Response.content : आप एक ही बार में सारा डेटा चाहते हैं।
• Response.iter_lines() और Response.iter_content() : आप एक बार में सभी डेटा नहीं चाहते हैं।
• Response.raw : आप अन्य दो विकल्पों से खुश नहीं हैं इसलिए इसे स्वयं करें।

इन्हें इसलिए चुना गया क्योंकि ये अनुरोधों के सामान्य उपयोगों का अत्यधिक प्रतिनिधित्व करते हैं। आपने कहा है " अधिकांश उपयोगकर्ता वैसे भी सामग्री पुनरावृत्तियों की परवाह नहीं करेंगे " और " response.stream एक ऐसी सुविधा है जो अधिकांश स्ट्रीमिंग उपयोगकर्ता चाहते हैं "। इस परियोजना पर अनुभव मुझे असहमत होने के लिए प्रेरित करता है: बहुत से लोग सामग्री इटरेटर का उपयोग करते हैं, और बहुत से फ़ाइल जैसी वस्तुओं को सख्त नहीं चाहते हैं।

एक अंतिम बिंदु: यदि संपीड़न कनेक्शन का एक पारदर्शी बातचीत विवरण होना चाहिए, तो आपको urllib3 के खिलाफ उपयुक्त बग उठाना चाहिए, जो हमारे कनेक्शन तर्क को संभालता है।

मुझे खेद है कि आपको ऐसा लगता है कि अनुरोध आपके उपयोग के मामले के लिए अनुपयुक्त हैं।

मुझे आपका बिंदु मिलता है कि response.raw वर्तमान कार्यान्वयन में टूट गया है और यहां तक ​​​​कि आंशिक रूप से इससे सहमत हैं (आपको कम से कम हेडर को पार्स किए बिना संपीड़न विवरण प्राप्त करने में सक्षम होना चाहिए)।

हालांकि, आपका प्रस्ताव अभी भी एक सुविधा अनुरोध है...

@लुकासा
मैं वास्तव में नहीं देख सकता कि कैसे urllib3 के खिलाफ बग दाखिल करना अनुरोधों के एपीआई को ठीक करेगा, कम से कम सभी अपने आप में नहीं।

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

@schlamar
मैं सहमत हूं कि इसे इस तरह पढ़ा जा सकता है। मैं आपको विश्वास दिलाता हूं कि इस समस्या को हल करने वाली किसी भी चीज के लिए मैं ठीक हूं। यदि वहां पहुंचने के लिए एक नया टिकट खोलना आवश्यक है, तो ऐसा ही हो।

यदि वहां पहुंचने के लिए एक नया टिकट खोलना आवश्यक है, तो ऐसा ही हो।

मुझे अब भी लगता है कि फीचर फ्रीज होने के कारण केनेथ इसे अस्वीकार कर देंगे।

मैं इस समस्या को हल करने वाली किसी भी चीज़ के साथ ठीक हूँ

1. iter_content को फ़ाइल जैसी वस्तु के रूप में लपेटें या
2. हेडर को पार्स करें और उचित होने पर response.raw डीकंप्रेस करें

दोनों समाधान उपरोक्त टिप्पणियों में हैं, बाद वाला आपके द्वारा पोस्ट किया गया। यह ऐसे मुद्दे क्यों हैं कि यह सीधे अनुरोध में नहीं होगा?

आइए यहां 100% स्पष्ट हों: मूल रूप से कोई मौका नहीं है कि यह अनुरोधों में शामिल हो जाएगा, जबकि यह फीचर फ्रीज में है। कुछ भी नहीं टूटा है, एपीआई आपकी आवश्यकताओं के लिए बिल्कुल सही नहीं है। क्योंकि कुछ भी टूटा नहीं है, केवल एक चीज जो मायने रखती है वह यह है कि क्या केनेथ इसे चाहता है। अनुरोध लोकतंत्र नहीं है, यह एक व्यक्ति एक वोट है। केनेथ आदमी है, उसके पास वोट है । केनेथ ने 8 महीने पहले इस मुद्दे को बंद कर दिया था, इसलिए ऐसा लगता है कि वह इसे नहीं चाहते हैं।

मैं वास्तव में नहीं देख सकता कि कैसे urllib3 के खिलाफ बग दाखिल करना अनुरोधों के एपीआई को ठीक करेगा, कम से कम सभी अपने आप में नहीं।

असंपीड़ित फ़ाइल-ऑब्जेक्ट को हमेशा वापस करने के लिए urllib3 को पैच करना इसे स्वयं ही हल करना चाहिए (यह नहीं कहा कि यह एक अच्छा विचार है)।

ओह, यहाँ समाधान संख्या 3 (अनचाहे) है:

response.raw.read = functools.partial(response.raw.read, decode_content=True)

देखें https://github.com/shazow/urllib3/blob/master/urllib3/response.py#L112

दिलचस्प - मुझे नहीं पता था कि अब तक अस्तित्व में है। यह निश्चित रूप से सुविधा को लपेटना बहुत आसान बनाता है।

हालांकि, क्या यह वास्तव में काम करता है? यानी डीकंप्रेसर स्टेटफुल और इंक्रीमेंटल हैं? पढ़ने के लिए दूसरी कॉल(123) उदाहरण के लिए, अब gzip फ़ाइल की वैध शुरुआत नहीं लौटाएगी।

हालांकि, क्या यह वास्तव में काम करता है? यानी डीकंप्रेसर स्टेटफुल और इंक्रीमेंटल हैं?

ओह, ऐसा नहीं लगता। मैंने डॉकस्ट्रिंग नहीं पढ़ा।

हालाँकि, यहाँ मेरा प्रस्ताव है:

1. urllib3 को पैच करें ताकि HTTPResponse.read amt और decode_content साथ एक साथ काम करे।
2. HTTPResponse._decode_content को एक सार्वजनिक सदस्य बनाएं (ताकि आप read पद्धति को पैच करने के बजाय response.raw.decode_content = True कर सकें)।
3. decode_content=True में iter_content decode_content=True का उपयोग करके अनुरोधों में डीकंप्रेसन को पूरी तरह से कम करें

@ लुकासा मुझे लगता है कि यह फीचर फ्रीज का उल्लंघन नहीं करेगा, है ना?

@schlamar : सिद्धांत रूप में, निश्चित रूप से। जब तक एपीआई अपरिवर्तित रहता है, आंतरिक परिवर्तन _ चाहिए_ ठीक है, और मैं इस पर +1 करूंगा। हालांकि, ध्यान रखें कि मैं BDFL नहीं हूं, =)

https://github.com/shazow/urllib3/pull/159

अनुरोधों में stream_decompress वैसे भी टूटा हुआ है: #1249

+1