Discussion :

[meles]

Bonjour,
lorsque j'étais en python 2.7, je pouvais parser un fichier texte compressé pour réaliser mes traitements. Depuis 3.3, les données lues sont binaires et mes traitements échouent:

Voici un ecm :
soit un fichier foo.txt, foo.zip (contenant le foo.txt compressé)!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
from zipfile import ZipFile
 
bar=(ZipFile('foo.zip')).open('foo.txt')
foo=open('foo.txt','r')
 
for ligne in foo:
    print(ligne.strip('\n'))
 
print("Zippé maintenant")
for ligne in bar:
    print(ligne)
    print(ligne.strip('\n'))

Résultats en 2.7:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
AAA
BBB
CCC
DDD
Zippé maintenant
AAA
BBB
CCC
DDD

Résultats en 3.3:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
AAA
BBB
CCC
DDD
Zippé maintenant
b'AAA\n'
Traceback (most recent call last):
  File "ecm.py", line 15, in <module>
    print(ligne.strip('\n'))
TypeError: Type str doesn't support the buffer API

J'aimerai, si possible éviter de désarchiver temporairement le fichier à lire.

Cordialement

[wiztricks]

Salut,
Avec Python3, les fichiers ouverts 'r' sont lus en unicode et les "str" sont unicode par défaut.

=> Pour avoir des bytes sur le fichier à zipper:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foo=open('foo.txt','rb')

Par contre, ZipFile().open() retournera maintenant des bytes (en fait pareil qu'avant...) mais dans:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
for ligne in bar:
    print(ligne)
    print(ligne.strip('\n'))

ligne est "bytes" alors que '\n' est "str" (et donc unicode).
Forcez '\n' à bytes via un b'\n' : çà "fonctionnera mieux".

Cordialement,
- W

[meles]

Forcez '\n' à bytes via un b'\n' : çà "fonctionnera mieux".

Merci de cette réponse rapide, je préfèrerai forcer "ligne" en Unicode (en str) puisque il ne s'agissait la que d'un exemple minimum.

En réalité, mes traitements sur la ligne sont plus complexe, et il ne peuvent être fait que ci celle ci en en 'str'.

Me reste à trouver comment la convertir en 'str' (j'espérai secrètement qu'un parametre de zipfile m'avait échappé pour me permettre de lire la ligne en 'str' directement)
@+

[meles]

Bonsoir,
un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ligne = ligne.decode()

semble faire l'affaire.

Cordialement

[wiztricks]

Salut,

Effectivement çà le fait pourvu que vous ayez tout "bytes" ou tout "str" et non un mix. Mais .decode suppose connaître l'encoding des fichiers pour fonctionner proprement.

- W

[meles]

Oui, jai du préciser decode('utf-8','ignore'). C'est pour un usage peso, alors je débogue au fur et à mesure.

Moi qui croyais que python 3.3 allait enfin me permettre d’arrêter de me prendre la tête avec des histoire d'encoding, c''est rapé !

@+

[wiztricks]

Salut,

Oui, jai du préciser decode('utf-8','ignore'). C'est pour un usage peso, alors je débogue au fur et à mesure.

hmm, utf-8 est le défaut.
Par contre, 'ignore' fera que les séquences de bytes intraduisibles seront virées.
est-ce vraiment ce que vous voulez?

Moi qui croyais que python 3.3 allait enfin me permettre d’arrêter de me prendre la tête avec des histoire d'encoding, c''est rapé !

Chaque fois que vous devez lire des textes externes et les transformer en Unicode "interne", il faut se poser la question. Python3 change les défauts et évite de mélanger bytes et unicode dans la même séquence.

Je ne comprends pas trop la nécessité des traitements que vous faites sur les fichiers archivés: si vous y touchez, non seulement vous perdez la conformité avec l'original mais devez décider de les garder en tas de bytes ou de les passer par .decode pour avoir des str.

Je suis curieux du "pourquoi" de ces traitements.
- W

[meles]

Bonsoir, pour virer les caractère inconnu sur mes fichiers (qui sont ascii en fait), le 'ignore' ne me gène pas.

Le pourquoi des traitements, pour satisfaire ta curiosité (votre si tu prèfères, mais le tutoiement étant de rigueur sur internet, j'y souscris volontiers) est en fait assez simple.

Tous les mois, je dois envoyer des fichiers produits par mon établissement à ma tutelle. Les envois sont réalisé avec des outils fournis par le ministère (qui sont soit java, soit dot net, beurk) et les données envoyées (des fichiers txt aux formats ésotériques qui changent régulièrement) sont stockées dans deux archives de type avant /après traitement. chaque fichier zip contient plusieurs de ces fichiers texte.

Mes "traitements" consistent à récupérer les infos contenues dans ces fichiers pour les coller dans une BDD afin des vérifier les résultats de ma tutelle (et procéder à différentes requêtes). Comme j'ai la flemme d'extraire tout ces fichiers (qui prennent bien moins de place dans leur format zip, certains peuvent faire plusieurs dizaine de milliers de lignes, parfois millions dans de très grosse structure), je traite tout ça directement en les lisant dans le zip, mais n'y apporte aucune modifs.

Mes traitements sont basé sur la récupération d'un ligne, puis initialisation d'une classe avec cette ligne comme paramètre du self.__init__, la classe en question se chargeant de trouver le bon format et de découper la ligne correctement (et d'y apporter un certain nombre de traitements pour rendre ces données aptes à être digérées par postgresql. J'ai d'ailleurs un grosse soucis de perf a cause de cette approche car l'instanciation (si c'est comme ça qu'on dit) d'un objet prend un temps fou, et sur un fichier de 2 Millions de lignes, c'est long.

Pour corser le tout, je bosse sous win au boulot, et linux à la maison (je suis de ceux qui emmènent du taff pour le soir).

En espérant avoir répondu a tes questions

[wiztricks]

Salut,

Merci pour ces infos.

J'ai d'ailleurs un grosse soucis de perf a cause de cette approche car l'instanciation (si c'est comme ça qu'on dit) d'un objet prend un temps fou, et sur un fichier de 2 Millions de lignes, c'est long.

S'il faut avoir analysé les 2M lignes, il faudra, en effet, du temps pour sortir d'__init__. Aller plus vite devrait être possible en "parallélisant" les traitements.
Mais ce n'est jamais simple.

- W