Requests: 압축되지 않은 콘텐츠를 파일과 같은 객체로 읽을 수 있는 방법이 없습니다.

Response.iter_content

음, 아니요, 그것은 반복자입니다. 나는 파일과 같은 객체, 즉 문서 프로세서가 직접 읽을 수 있는 객체를 요구했습니다.

iter_content 로 파일과 같은 객체를 만드는 것은 매우 간단합니다.

빠른 답변 감사합니다, BTW.

나는 동의한다. 그래도 requests 에서 이 기능을 제공하는 것이 훨씬 더 쉬울 것입니다. 내 요점은 .raw 가 전송 수준 세부 정보를 노출하기 때문에 스트림에서 읽으려는 대부분의 사용 사례에 대해 잘못된 추상화 수준이라는 것입니다.

개인적으로 HTTP 요청 결과에 대해 줄 단위로 반복하거나 청크 단위로 반복하는 주요 사용 사례는 보지 못하지만 파일과 같은 객체, 특히 응답 형식으로 구문 분석하는 몇 가지 주요 사용 사례를 봅니다. HTML, XML, Json 등과 같은 문서 파서가 필요한

또한 파일류 객체를 래핑하는 반복자를 작성하는 것이 반복자를 래핑하는 파일류 객체보다 작성하는 것이 훨씬 쉽습니다.

다음 코드를 생각해 냈습니다. 필요한 모든 경우를 처리하지만 다소 복잡합니다. 그래서 도서관의 일부로 이런 것을 갖고 싶다고 말한 것입니다. 사용자는 이것을 스스로 알아낼 필요가 없습니다.

나는 requests' models.py 내부의 코드가 여기서 잘못된 추상화를 사용한다고 생각합니다. 반복하는 동안이 아니라 반복 기계로 시작하기 _전에_ 원시 스트림의 압축을 풀어야 합니다. 파일류에서 반복자로 돌아가서 파일류로 돌아가는 것은 그저 어리석은 일입니다. 단일 API 변환으로 충분하며 대부분의 사용자는 어쨌든 콘텐츠 반복기에 대해 신경 쓰지 않을 것입니다.

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

내 의견, 특히 내가 게시한 코드 앞의 단락을 다시 읽고 싶을 수도 있습니다.

예, 하지만 이 솔루션은 이미 요청에 내장되어 있기 때문에 두 번째 위치에서 압축 해제를 수행하는 것보다 여전히 깨끗하고(IMO가 더 쉽습니다).

그러나 일반적으로 r.file (또는 이와 유사한 것)에는 r.raw 보다 훨씬 더 많은 사용 사례가 있다는 데 동의합니다. 그래서 이것도 리퀘스트에 포함되었으면 하는 바램입니다. @kennethreitz

"response.stream"은 나에게 좋은 이름처럼 들립니다.

이것이 response.raw의 용도입니다 :)

저도 보고 직감적으로 그렇게 생각했습니다. 그러나 사용자가 신경 쓰지 않아도 되는 기본 전송 계층의 내부 세부 정보를 노출하기 때문에 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로 다시 인코딩하는 것입니다.

이것은 버그가 _아닙니다_, 당신이 제안한 버그는 확실히 아닙니다. 파일류 객체가 정말로 필요하다면 StringIO와 BytesIO를 추천합니다.

@루카사 맞습니다. content 는 항상 바이트열이어야 합니다(Python 3에서는 명시적 바이트열이고 Python 2에서는 str == bytes). 바이트열이 아닌 유일한 항목은 text 입니다.

@kennethreitz 이에 대한 소식이 있습니까? 이것은 매우 심각한 디자인 버그이며 조기에 해결하는 것이 가장 좋습니다. 이 문제를 해결하기 위해 더 많은 코드가 작성될수록 모두에게 더 많은 비용이 듭니다.

이것은 디자인 버그가 아니라 기능 요청일 뿐입니다. 그리고 요청에 기능 정지 가 있기 때문에 이것이 곧 요청에 포함되지 않을 것이라고 가정합니다(만약 있다면)...

나는 오래 지속되는 디자인 버그를 "누락된 기능"으로 다시 선언하지 않는다고 생각합니다.
너무 쉽게 사라지게 만듭니다. 작가가 고민하고 있다고 들었다.
"요청"을 Python stdlib의 일부로 만듭니다. 그게 좋을거야
이것을 고칠 기회.

작가가 고민하고 있다고 들었다.
"요청"을 Python stdlib의 일부로 만듭니다.

실제로는 아닙니다: http://docs.python-requests.org/en/latest/dev/philosophy/#standard -library

이것은 버그가 아니라 기능 요청입니다. 요청은 아무 잘못도 하지 않고 단순히 선택적인 일을 하지 않는 것입니다. 그것이 바로 기능의 정의입니다.

또한 stdlib를 준비하는 것이 바로 요청이 기능 정지 상태에 있는 이유입니다. 요청이 stdlib에 있으면 적시에 버그를 수정하기가 매우 어려워집니다. 결과적으로 새 기능을 추가하면 버그가 추가되거나 동작이 퇴행하는 경우 다음 마이너 릴리스까지 stdlib의 버전을 수정할 수 없습니다. 그것은 나쁠 것입니다.

마크 슐라이히, 19.03.2013 08:41:

작가가 고민하고 있다고 들었다.
"요청"을 Python stdlib의 일부로 만듭니다.

실제로는 아닙니다: http://docs.python-requests.org/en/latest/dev/philosophy/#standard -library

나는 그것을 여기에서 읽었다:

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

스테판

이것이 기능 요청이 아닌 디자인 버그인 이유는 이미 설명했습니다. 기존 API는 잘못된 추상화를 사용하고 연결의 협상 세부 정보를 원격 사이트에 따라 사용자 공간으로 누출하므로 사용자가 신경써야 합니다. 이는 현재 원시 스트림 읽기 지원을 사용하기 어렵게 만듭니다. 본질적으로 이것은 새로운 기능에 대한 요청이 아니라 손상된 기능을 수정하기 위한 요청입니다.

깔끔하게 정리해드리겠습니다. 버그는 원시 스트림 읽기 기능의 실제 사용이 라이브러리의 일부, 특히 전체 조건부 스트림 압축 해제 부분을 다시 구현해야 한다는 것입니다. 클라이언트가 압축을 허용하는 즉시 기능이 없으면 기능이 쓸모가 없기 때문입니다. 우리는 "요청"에 이미 있는 코드에 대해 이야기하고 있습니다. 잘못된 위치에서 사용되었을 뿐입니다. 클라이언트가 서버가 수락 헤더를 존중하는지 여부를 제어할 수 없기 때문에 원시 읽기 수준보다 낮은 수준에서 사용해야 합니다. 압축은 연결의 투명한 협상 세부 사항이어야 하며, 관련 헤더를 활성화하는 사용자에게 피해를 주지 않아야 합니다.

클라이언트가 압축된 스트림에 관심을 가질 사용 사례는 생각할 수 없습니다. 특히 서버가 클라이언트의 희망을 기쁘게 무시할 수 있기 때문에 스트림이 실제로 압축되는지 여부를 예측할 수 없는 경우에는 더욱 그렇습니다. 순수한 협상 세부 사항입니다. 이것이 원시 스트림 읽기가 가장 일반적인 것보다 극히 가능성이 낮은 사용 사례를 선호하여 잘못된 추상화를 사용하는 이유입니다.

저 할 수 있어요. 예를 들어 대용량 텍스트 기반 파일을 다운로드하고 압축된 상태로 유지하려면 어떻게 해야 합니까? No way to save original-compressed data to disk 라는 제목의 새로운 '디자인 버그'로 이 변경 사항을 추적할 수 있습니다.

그 아이디어는 의도적으로 진부하고 어리석은 것이지만 요점을 설명하려고 합니다. 즉, 요청이 모든 사람에게 그들이 원하는 상호 작용 메커니즘을 정확히 제공할 의무는 없습니다. 실제로 그렇게 하는 것은 API의 단순성인 Requests의 주요 목표에 직접적으로 반대되는 실행이 됩니다. 유용한 기능을 추가했음에도 불구하고 API를 복잡하게 하기 때문에 이의가 제기된 요청에 대한 길고 긴_ 제안된 변경 목록이 있습니다. 요청은 모든 사용 사례에 대해 urllib2를 대체하는 것을 목표로 하지 않으며 가장 일반적인 경우를 단순화하는 것을 목표로 합니다.

이 경우 Requests는 대부분의 사용자가 파일과 같은 객체를 원하지 않는다고 가정하므로 다음과 같은 상호 작용을 제안합니다.

• Response.text 및 Response.content : 모든 데이터를 한 번에 원합니다.
• Response.iter_lines() 및 Response.iter_content() : 모든 데이터를 한 번에 원하는 것은 아닙니다.
• Response.raw : 다른 두 가지 옵션이 마음에 들지 않으니 직접 하십시오.

이들은 Requests의 일반적인 용도를 압도적으로 대표하기 때문에 선택되었습니다. 당신은 " 대부분의 사용자는 어쨌든 콘텐츠 반복자에 대해 신경 쓰지 않을 것 "이라고 말했고 " response.stream 는 대부분의 스트리밍 사용자가 원하는 기능입니다 ". 이 프로젝트에 대한 경험은 동의하지 않습니다. 많은 사람들이 콘텐츠 반복자를 사용하고 파일과 같은 객체를 간절히 원하는 사람은 많지 않습니다.

마지막 요점: 압축이 연결의 투명한 협상 세부 사항이어야 하는 경우 연결 논리를 처리하는 urllib3에 대해 적절한 버그를 제기해야 합니다.

요청이 귀하의 사용 사례에 부적절하다고 느끼셨다니 유감입니다.

현재 구현에서 response.raw 가 손상되었으며 부분적으로는 이에 동의합니다(적어도 헤더를 구문 분석하지 않고 압축 세부 정보를 얻을 수 있어야 함).

그러나 귀하의 제안은 여전히 ​​기능 요청입니다 ...

@루카사
urllib3에 대한 버그 신고가 요청의 API를 수정하는 방법을 알 수 없습니다. 적어도 그 자체는 아닙니다.

그리고 귀하의 "사용 사례"가 고안되었다는 데 동의합니다. 내가 말했듯이 클라이언트가 서버 측에서 압축을 적극적으로 제어할 수 없는 경우(비활성화하지만 안정적으로 활성화하지 못하는 경우) 압축 파일을 디스크에 저장할 수 있도록 클라이언트에 의존하는 것은 그다지 흥미롭지 않습니다. .

@schlamar
그렇게 읽을 수 있다는 점에 동의합니다. 나는 이 문제를 해결하는 어떤 것이든 괜찮다고 확신합니다. 거기에 가기 위해 새 티켓을 여는 것이 필요하다면 그렇게 하십시오.

거기에 가기 위해 새 티켓을 여는 것이 필요하다면 그렇게 하십시오.

나는 여전히 Kenneth가 기능 정지로 인해 이것을 거부할 것이라고 생각합니다.

나는 이 문제를 해결하는 모든 것이 좋다

1. iter_content 를 파일류 객체로 감싸거나
2. 헤더를 구문 분석하고 적절한 경우 response.raw 압축을 해제합니다.

두 가지 솔루션 모두 위의 댓글에 있으며 후자는 귀하가 게시한 것입니다. 이것이 요청에 직접 포함되지 않는 것이 왜 그러한 문제입니까?

여기에서 100% 명확히 합시다. 기본적으로 기능이 정지된 동안 요청에 들어갈 가능성은 없습니다. 고장난 것은 없으며 API가 귀하의 요구에 완벽하지 않습니다. 고장난 것이 없기 때문에 중요한 것은 Kenneth가 원하는지 여부뿐입니다. 요청은 민주주의가 아니라 1인 1표입니다. Kenneth는 남자이고 그는 투표권을 가지고 있습니다. Kenneth는 8개월 전에 이 문제를 닫았으므로 그가 그것을 원하지 않는다는 것이 꽤 분명한 것 같습니다.

urllib3에 대한 버그 신고가 요청의 API를 수정하는 방법을 알 수 없습니다. 적어도 그 자체는 아닙니다.

압축되지 않은 파일 개체를 항상 반환하도록 urllib3을 패치하면 이 문제가 저절로 해결됩니다(좋은 생각은 아닙니다).

아, 솔루션 번호 3(테스트되지 않음)이 있습니다.

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

https://github.com/shazow/urllib3/blob/master/urllib3/response.py#L112 참조

흥미롭다 - 나는 그것이 지금까지 존재하는지 몰랐습니다. 그러면 기능을 훨씬 쉽게 래핑할 수 있습니다.

하지만 실제로 작동합니까? 즉, 압축 해제기가 상태 저장 및 증분입니까? 예를 들어, 두 번째 read(123) 호출은 더 이상 gzip 파일의 유효한 시작을 반환하지 않습니다.

하지만 실제로 작동합니까? 즉, 압축 해제기가 상태 저장 및 증분입니까?

오, 그렇지 않은 것 같습니다. 나는 독스트링을 읽지 않았다.

그러나 여기 내 제안이 있습니다.

1. HTTPResponse.read 가 amt 및 decode_content 동시에 작동하도록 urllib3을 패치합니다.
2. HTTPResponse._decode_content를 공개 멤버로 만듭니다( read 메서드를 패치하는 대신 response.raw.decode_content = True 를 수행할 수 있음).
3. decode_content=True 에서 iter_content decode_content=True 를 사용하여 요청에서 완전히 압축 해제

@Lukasa 기능 정지를 위반하지는 않을 것 같은데요?

@schlamar : 원칙적으로

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

어쨌든 요청의 stream_decompress 가 깨졌습니다: #1249

+1