Requests: aucun moyen de lire le contenu non compressé en tant qu'objet de type fichier

Response.iter_content

Euh, non, c'est un itérateur. Je demandais un objet de type fichier, c'est-à-dire quelque chose que les processeurs de documents peuvent lire directement.

Il serait assez simple de créer un objet de type fichier avec iter_content

Merci pour la réponse rapide, BTW.

Je suis d'accord. Pourtant, il serait encore plus facile pour requests de fournir cette fonctionnalité. Mon argument est que .raw n'est pas le bon niveau d'abstraction pour la plupart des cas d'utilisation qui souhaitent lire à partir du flux, car il expose les détails du niveau de transfert.

Personnellement, je ne vois pas de cas d'utilisation majeur pour l'itération ligne par ligne ou même morceau par morceau sur le résultat d'une requête HTTP, mais je vois plusieurs cas d'utilisation majeurs pour l'analyser en tant qu'objet de type fichier, en particulier les formats de réponse qui nécessitent un analyseur de document, tel que HTML, XML, Json, etc.

Notez également qu'il est beaucoup plus facile d'écrire un itérateur qui encapsule un objet de type fichier qu'un objet de type fichier qui encapsule un itérateur.

Je suis venu avec le code suivant. Il gère tous les cas nécessaires, mais je le trouve assez complexe. C'est pourquoi j'ai dit que je voulais quelque chose comme ça dans le cadre de la bibliothèque. Les utilisateurs ne devraient pas avoir à le découvrir eux-mêmes.

Je pense que le code à l'intérieur de models.py des requêtes utilise la mauvaise abstraction ici. Il doit décompresser le flux brut _avant_ de démarrer avec sa machinerie d'itération, pas pendant l'itération. Passer d'un type de fichier à un itérateur juste pour revenir à un type de fichier est tout simplement stupide. Une seule transformation d'API est plus que suffisante et la plupart des utilisateurs ne se soucieront pas des itérateurs de contenu de toute façon.

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

Pourquoi ne pas construire l'objet de type fichier à partir de content_iter comme proposé. Cela pourrait ressembler à :

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

Vous voudrez peut-être relire mon commentaire, en particulier le paragraphe qui précède le code que j'ai posté.

Oui, mais cette solution est toujours plus propre (et IMO plus facile) que de faire la décompression à un deuxième endroit car cela est déjà intégré dans les requêtes.

Mais je suis d'accord avec vous en général, un r.file (ou quelque chose comme ça) a beaucoup plus de cas d'utilisation que r.raw . J'aimerais donc que cela soit également inclus dans les demandes. @kennethreitz

"response.stream" me semble être un bon nom.

C'est à ça que sert response.raw :)

C'est aussi ce que j'ai pensé intuitivement quand je l'ai vu. Mais ensuite, j'ai réalisé que response.raw est cassé car il expose des détails internes de la couche de transport sous-jacente dont les utilisateurs ne devraient pas avoir à se soucier.

La seule méthode dont ils devraient avoir besoin est raw.read ?

Eh bien, oui - sauf que raw.read() se comporte différemment selon les négociations internes entre le client et le serveur. Il renvoie parfois les données attendues et parfois il renvoie des octets compressés nus.

Fondamentalement, response.raw est une fonctionnalité agréable que la plupart des utilisateurs ignoreraient volontiers et que certains utilisateurs expérimentés pourraient trouver utile, alors qu'un response.stream indépendant

+1

+1

Ce bug de conception va-t-il être corrigé ?

Je ne sais pas à quel point cette méthode est correcte ou efficace, mais pour moi, ce qui suit fonctionne :

>>> 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 : C'est une chose bizarre à faire. response.content est déjà une chaîne d'octets, donc ce que vous faites ici est de décoder le contenu avec le codec choisi par Python, puis de le ré-encoder en utf-8.

Ce n'est _pas_ un bogue, et ce n'est certainement pas le bogue que vous avez suggéré. Si vous avez vraiment besoin d'un objet de type fichier, je recommande StringIO et BytesIO.

@Lukasa a raison. content doit toujours être une chaîne d'octets (en Python 3, c'est une chaîne d'octets explicite ; en Python 2 str == octets). Le seul élément qui n'est pas une chaîne d'octets est text .

@kennethreitz des nouvelles à ce sujet ? Il s'agit d'un bug de conception assez sérieux et il est préférable de le régler tôt. Plus le code est écrit pour le contourner, plus il devient coûteux pour tout le monde.

Ce n'est pas un bug de conception, c'est juste une demande de fonctionnalité. Et comme les demandes ont un gel des fonctionnalités, je suppose que cela ne sera pas dans les demandes de sitôt (voire pas du tout) ...

Je ne pense pas que redéclarer un bug de conception de longue date une "fonctionnalité manquante"
le fait disparaître si facilement. J'ai entendu dire que l'auteur pense à
faire des "requêtes" une partie de la stdlib Python. ce serait une bonne
opportunité de corriger cela.

J'ai entendu dire que l'auteur pense à
faire des "requêtes" une partie de la stdlib Python.

Pas vraiment : http://docs.python-requests.org/en/latest/dev/philosophy/#standard -library

Ce n'est pas un bug, c'est une demande de fonctionnalité. Requests ne fait rien de mal, il ne fait tout simplement pas quelque chose qui est facultatif. C'est la définition même d'une fonctionnalité.

De plus, la préparation de la stdlib est exactement la raison pour laquelle Requests est en gel de fonctionnalités. Une fois que Requests est dans la stdlib, il devient très difficile de corriger les bogues en temps voulu. En conséquence, si l'ajout de la nouvelle fonctionnalité ajoute des bogues ou régresse le comportement, la version dans stdlib ne peut pas être corrigée avant la prochaine version mineure. Ce serait mauvais.

Marc Schlaich, 19.03.2013 08:41:

J'ai entendu dire que l'auteur pense à
faire des "requêtes" une partie de la stdlib Python.

Pas vraiment : http://docs.python-requests.org/en/latest/dev/philosophy/#standard -library

Je l'ai lu ici :

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

Stéphane

J'ai déjà expliqué pourquoi il s'agit d'un bogue de conception et non d'une demande de fonctionnalité : l'API existante utilise la mauvaise abstraction et diffuse les détails de négociation de la connexion dans l'espace utilisateur qui sont à la merci du site distant, et donc, que l'utilisateur ne doit pas avoir à se soucier. Cela rend le support de lecture de flux brut actuel difficile à utiliser. Il s'agit essentiellement d'une demande de réparation d'une fonctionnalité défaillante, et non d'une demande de nouvelle fonctionnalité.

Permettez-moi de résumer cela proprement. Le bogue est que toute utilisation réelle de la fonctionnalité de lecture de flux brut devra réimplémenter une partie de la bibliothèque, en particulier toute la partie de décompression conditionnelle de flux, car la fonctionnalité est inutile sans elle, dès que le client autorise la compression. Nous parlons ici de code qui est déjà là, dans "requests" - il est simplement utilisé au mauvais endroit. Il doit être utilisé en dessous du niveau de lecture brut, pas au-dessus, car le client ne peut pas contrôler si le serveur respecte l'en-tête d'acceptation ou non. La compression doit être un détail de négociation transparent de la connexion, et non quelque chose qui blesse un utilisateur qui active l'en-tête correspondant.

Je ne peux penser à aucun cas d'utilisation où le client serait intéressé par le flux compressé, surtout s'il ne peut pas prédire si le flux sera vraiment compressé ou non, car le serveur peut ignorer avec plaisir le souhait du client. C'est un pur détail de négociation. C'est pourquoi la lecture de flux bruts utilise la mauvaise abstraction en préférant le cas d'utilisation extrêmement improbable au plus courant.

Je peux. Par exemple, que se passe-t-il si vous téléchargez un fichier texte volumineux et que vous souhaitez le conserver compressé ? Je pourrais suivre ce changement avec un nouveau "bug de conception" intitulé Aucun moyen d'enregistrer les données compressées à l'origine sur le disque .

Cette idée est intentionnellement banale et stupide, mais j'essaie d'illustrer un point, qui est celui-ci : Requests n'est pas obligé d'offrir à chacun exactement le mécanisme d'interaction qu'il souhaite. En fait, cela irait directement à l'encontre de l'objectif principal de Requests, qui est la simplicité de l'API. Il existe une longue, longue, _longue_ liste de modifications proposées aux demandes qui ont fait l'objet d'une objection car elles compliquent l'API, même si elles ajoutent des fonctionnalités utiles. Requests ne vise pas à remplacer urllib2 pour tous les cas d'utilisation, il vise à simplifier les cas les plus courants.

Dans ce cas, Requests suppose que la plupart des utilisateurs ne veulent pas d'objets de type fichier et propose donc les interactions suivantes :

• Response.text et Response.content : Vous voulez toutes les données en une seule fois.
• Response.iter_lines() et Response.iter_content() : Vous ne voulez pas toutes les données en une seule fois.
• Response.raw : Vous n'êtes pas satisfait des deux autres options, alors faites-le vous-même.

Ceux-ci ont été choisis parce qu'ils représentent en très grande majorité les utilisations courantes des requêtes. Vous avez dit " la plupart des utilisateurs ne se soucieront pas des itérateurs de contenu de toute façon " et " response.stream est une fonctionnalité que la plupart des utilisateurs de streaming voudraient ". L'expérience sur ce projet m'amène à ne pas être d'accord : un grand nombre de personnes utilisent les itérateurs de contenu, et peu veulent désespérément des objets de type fichier.

Un dernier point : si la compression doit être un détail de négociation transparent de la connexion, alors vous devez signaler le bogue approprié contre urllib3, qui gère notre logique de connexion.

Je suis désolé que vous ayez l'impression que Requests est inapproprié pour votre cas d'utilisation.

Je comprends que response.raw est cassé dans l'implémentation actuelle et même partiellement d'accord avec cela (vous devriez au moins pouvoir obtenir les détails de la compression sans analyser les en-têtes).

Cependant, votre proposition est toujours une demande de fonctionnalité...

@Lukasa
Je ne vois pas vraiment comment le dépôt du bogue contre urllib3 corrigerait l'API des requêtes, du moins pas tout seul.

Et je suis d'accord que votre "cas d'utilisation" est inventé. Comme je l'ai dit, si le client ne peut pas contrôler positivement la compression côté serveur (et qu'il la désactive, mais ne l'active pas de manière fiable), alors compter sur lui pour pouvoir enregistrer un fichier compressé sur le disque n'est, eh bien, pas si intéressant .

@schlamar
Je suis d'accord qu'il peut être lu comme tel. Je vous assure que je suis d'accord avec tout ce qui résout ce problème. Si l'ouverture d'un nouveau billet est nécessaire pour s'y rendre, qu'il en soit ainsi.

Si l'ouverture d'un nouveau billet est nécessaire pour s'y rendre, qu'il en soit ainsi.

Je pense toujours que Kenneth rejettera cela en raison du gel des fonctionnalités.

Je suis d'accord avec tout ce qui résout ce problème

1. Enveloppez iter_content tant qu'objet de type fichier ou
2. Analysez les en-têtes et décompressez response.raw si nécessaire

Les deux solutions sont dans les commentaires ci-dessus, la dernière postée par vous. Pourquoi est-ce un tel problème que cela ne figure pas directement dans les demandes ?

Soyons clairs à 100 % ici : il n'y a pratiquement aucune chance que cela entre dans les demandes pendant le gel des fonctionnalités. Rien n'est cassé, l'API n'est tout simplement pas parfaite pour vos besoins. Parce que rien n'est cassé, la seule chose qui compte est de savoir si Kenneth le veut. Requests n'est pas une démocratie, c'est un homme une voix. Kenneth est l'homme, il a le vote . Kenneth a fermé ce problème il y a 8 mois, il semble donc assez clair qu'il n'en veut pas.

Je ne vois pas vraiment comment le dépôt du bogue contre urllib3 corrigerait l'API des requêtes, du moins pas tout seul.

Patcher urllib3 pour toujours renvoyer l'objet-fichier non compressé devrait résoudre ce problème par lui-même (on ne dit pas que c'est une bonne idée).

Oh, voici la solution numéro 3 (non testée) :

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

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

Intéressant - je ne savais pas que cela existait maintenant. Cela rend beaucoup plus facile d'envelopper la fonctionnalité, bien sûr.

Cependant, cela fonctionne-t-il réellement ? C'est-à-dire que les décompresseurs sont dynamiques et incrémentiels ? Le deuxième appel à read(123) ne renverra plus le début valide d'un fichier gzip, par exemple.

Cependant, cela fonctionne-t-il réellement ? C'est-à-dire que les décompresseurs sont dynamiques et incrémentiels ?

Oh, ça n'a pas l'air d'être le cas. Je n'ai pas lu la docstring.

Cependant, voici ma proposition :

1. Patch urllib3 pour que HTTPResponse.read fonctionne avec amt et decode_content simultanément.
2. Faites de HTTPResponse._decode_content un membre public (vous pouvez donc faire response.raw.decode_content = True au lieu de patcher la méthode read ).
3. Supprimez complètement la décompression dans les requêtes en utilisant decode_content=True dans iter_content

@Lukasa Je pense que cela ne violera pas le gel des fonctionnalités, n'est-ce pas ?

@schlamar : En principe, bien sûr. Tant que l'API reste inchangée, les changements internes _devraient_ être ok, et je serais +1 sur celui-ci. Cependant, gardez à l'esprit que je ne suis pas le BDFL, =)

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

stream_decompress dans les requêtes est cassé de toute façon : #1249

+1