Requests: 圧縮されていないコンテンツをファイルのようなオブジェクトとして読み取る方法はありません

Response.iter_content

えーと、いや、それはイテレータです。 私はファイルのようなオブジェクト、つまりドキュメントプロセッサが直接読み取ることができるオブジェクトを求めていました。

iter_contentを使用してファイルのようなオブジェクトを作成するのは非常に簡単です。

ところで、迅速な返信をありがとう。

同意します。 それでも、 requestsがこの機能を提供するのはさらに簡単です。 私のポイントは、 .rawは、転送レベルの詳細を公開するため、ストリームから読み取りたいほとんどのユースケースにとって間違ったレベルの抽象化であるということです。

個人的には、HTTPリクエストの結果を1行ずつ、またはチャンクごとに繰り返す主なユースケースは見当たりませんが、ファイルのようなオブジェクト、特に応答形式として解析する主なユースケースはいくつか見られます。 HTML、XML、Jsonなどのドキュメントパーサーが必要です。

また、イテレータをラップするファイルのようなオブジェクトよりも、ファイルのようなオブジェクトをラップするイテレータを作成する方がはるかに簡単であることに注意してください。

私は次のコードを思いついた。 必要なすべてのケースを処理しますが、かなり複雑だと思います。 だから私は図書館の一部としてこのようなものが欲しいと言ったのです。 ユーザーはこれを自分で理解する必要はありません。

requestの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

私のコメント、特に私が投稿したコードの前の段落をもう一度読みたいと思うかもしれません。

はい。ただし、このソリューションはすでにリクエストに組み込まれているため、2番目の場所で解凍を実行するよりもクリーンです（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はすでにバイト文字列であるため、ここで行っているのは、Pythonが選択した地獄のコーデックでコンテンツをデコードしてから、utf-8として再エンコードすることです。

これはバグではなく、あなたが提案したバグではありません。 ファイルのようなオブジェクトが本当に必要な場合は、StringIOとBytesIOをお勧めします。

@Lukasaは正しいです。 contentは常にバイト文字列である必要があります（Python3では明示的なバイト文字列です。Python2ではstr ==バイトです）。 バイトストリングではない唯一のアイテムはtextです。

@kennethreitzこれに関するニュースはありますか？ これはかなり深刻な設計上のバグであり、早期に解決するのが最善です。 それを回避するために書かれるコードが多ければ多いほど、それは誰にとってもコストがかかります。

これは設計上のバグではなく、単なる機能の要求です。 そして、リクエストには機能のフリーズがあるので、これはすぐにリクエストに含まれないと思います（もしあれば）...

長年の設計バグを再宣言することは「欠けている機能」ではないと思います
簡単に消えてしまいます。 著者が考えていると聞きました
Pythonstdlibの一部として「リクエスト」を作成します。 それは良いことです
これを修正する機会。

著者が考えていると聞きました
Pythonstdlibの一部として「リクエスト」を作成します。

実際にはそうではありません： http： //docs.python-requests.org/en/latest/dev/philosophy/#standard -library

これはバグではなく、機能のリクエストです。 リクエストは何も悪いことをしていません、それは単にオプションの何かをしていません。 それがまさに機能の定義です。

さらに、stdlibの準備は、Requestsが機能フリーズになっている理由です。 Requestsがstdlibに入ると、タイムリーなバグ修正を行うことが非常に困難になります。 その結果、新機能を追加するとバグやリグレッションの動作が追加された場合、stdlibのバージョンは次のマイナーリリースまで修正できません。 それは悪いことです。

Marc Schlaich、19.03.2013 08:41：

著者が考えていると聞きました
Pythonstdlibの一部として「リクエスト」を作成します。

実際にはそうではありません： 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は間違った抽象化を使用し、接続のネゴシエーションの詳細をリモートサイトに翻弄されるユーザースペースにリークするため、ユーザーはすべきではありません。気にする必要があります。 そのため、現在の生のストリーム読み取りサポートは使いにくくなっています。 基本的に、これは壊れた機能を修正するためのリクエストであり、新しい機能のリクエストではありません。

これをきれいに要約しましょう。 バグは、生のストリーム読み取り機能を実際に使用する場合、クライアントが圧縮を許可するとすぐに、ライブラリの一部、特に条件付きストリーム解凍部分全体を再実装する必要があることです。これがないと機能は役に立たないためです。 ここでは、「リクエスト」ですでに存在するコードについて話します。これは、間違った場所で使用されているだけです。 サーバーがacceptヘッダーを尊重するかどうかをクライアントが制御できないため、未加工の読み取りレベルより下で使用する必要があります。 圧縮は、関連するヘッダーを有効にするユーザーを傷つけるものではなく、接続の透過的なネゴシエーションの詳細である必要があります。

サーバーがクライアントの希望を喜んで無視できるため、特にストリームが実際に圧縮されるかどうかを予測できない場合、クライアントが圧縮ストリームに関心を持つユースケースは考えられません。 それは純粋な交渉の詳細です。 そのため、生のストリームの読み取りでは、最も一般的なユースケースよりも非常にありそうもないユースケースを優先することで、間違った抽象化を使用します。

私はできる。 たとえば、大きなテキストベースのファイルをダウンロードしていて、それを圧縮したままにしておきたい場合はどうでしょうか。 この変更を、元々圧縮されたデータをディスクに保存する方法がないというタイトルの新しい「設計バグ」でフォローアップすることができます。

そのアイデアは意図的に陳腐で愚かですが、私はポイントを説明しようとしています。それは、リクエストがすべての人に彼らが望む相互作用メカニズムを正確に提供する義務はないということです。 実際、そうすることは、リクエストが持つ主な目標であるAPIの単純さに直接反することになります。 有用な機能を追加したにもかかわらず、APIを複雑にするために反対された、リクエストに対する提案された変更の長い、長い、_長い_リストがあります。 Requestsは、すべてのユースケースでurllib2を置き換えることを目的としておらず、最も一般的なケースを単純化することを目的としています。

この場合、Requestsは、ほとんどのユーザーがファイルのようなオブジェクトを望まないと想定しているため、次の相互作用を提案します。

• Response.textおよびResponse.content ：すべてのデータを一度に取得する必要があります。
• Response.iter_lines()およびResponse.iter_content() ：一度にすべてのデータが必要になるわけではありません。
• Response.raw ：他の2つのオプションに満足していないので、自分で行ってください。

これらは、リクエストの一般的な使用法を圧倒的に表すために選択されました。 「ほとんどのユーザーはとにかくコンテンツイテレータを気にしない」とあなたは言いました、そして「 response.streamはほとんどのストリーミングユーザーが望む機能です」。 このプロジェクトの経験から、私は意見が分かれます。非常に多くの人がコンテンツイテレータを使用しており、ファイルのようなオブジェクトを必死に望んでいる人は多くありません。

最後のポイント：圧縮が接続の透過的なネゴシエーションの詳細である必要がある場合は、接続ロジックを処理するurllib3に対して適切なバグを発生させる必要があります。

リクエストがユースケースに不適切であると思われることをお詫び申し上げます。

response.rawは現在の実装では壊れており、部分的にも同意しているとのことです（少なくとも、ヘッダーを解析せずに圧縮の詳細を取得できるはずです）。

ただし、あなたの提案はまだ機能要求です...

@ルカサ
urllib3に対してバグを報告すると、少なくともすべてが単独でではなく、リクエストのAPIがどのように修正されるかはわかりません。

そして、私はあなたの「ユースケース」が考案されていることに同意します。 私が言ったように、クライアントがサーバー側で圧縮を積極的に制御できない場合（そしてそれを無効にするが、確実に有効にしない場合）、圧縮ファイルをディスクに保存できるようにするためにクライアントに依存することは、まあ、それほど興味深いことではありません。

@schlamar
私はそれがそのように読めることに同意します。 私はこの問題を解決するものなら何でも大丈夫だとあなたに保証します。 そこにたどり着くために新しいチケットを開く必要がある場合は、そうしてください。

そこにたどり着くために新しいチケットを開く必要がある場合は、そうしてください。

機能がフリーズしたため、ケネスはこれを拒否すると思います。

私はこの問題を解決するものなら何でも大丈夫です

1. iter_contentをファイルのようなオブジェクトとしてラップするか
2. ヘッダーを解析し、必要に応じてresponse.rawを解凍します

両方の解決策は上記のコメントにあり、後者はあなたが投稿したものです。 これが直接リクエストに含まれないのはなぜですか？

ここで100％明確にしましょう。基本的に、機能がフリーズしている間は、これがリクエストに含まれる可能性はありません。 壊れているものはありません。APIはニーズに完全ではありません。 何も壊れていないので、重要なのはケネスがそれを望んでいるかどうかだけです。 要求は民主主義ではなく、一人一票です。 ケネスは男です、彼は投票権を持っています。 ケネスは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）を2回呼び出すと、gzipファイルの有効な開始が返されなくなります。

しかし、それは実際に機能しますか？ つまり、デコンプレッサはステートフルでインクリメンタルですか？

ああ、そうではないようです。 私はdocstringを読んでいませんでした。

しかし、ここに私の提案があります：

1. HTTPResponse.readがamtおよびdecode_contentと同時に機能するようにurllib3にパッチを適用します。
2. HTTPResponse._decode_contentをパブリックメンバーにします（これにより、 readメソッドにパッチを適用する代わりにresponse.raw.decode_content = True実行できます）。
3. iter_content decode_content=Trueを使用して、リクエストの解凍を完全に削除します

@Lukasaこれは機能のフリーズに違反しないと思いますよね？

@schlamar ：原則として、確かに。 APIが変更されていない限り、内部の変更は問題ないはずです。これは+1になります。 ただし、私はBDFLではないことに注意してください=）

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

リクエストのstream_decompressはとにかく壊れています：＃1249

+1