pack_into et buffer modifiable

Bonjour,

j'ai un petit code tout gentil qui veut écrire des données binaires dans un fichier.

Code:

---

1 2 3 4 5

>>> import struct >>> output = struct.pack( 'II',1,2 ) >>> output += struct.pack( 'II',3,4 ) >>> output '\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04\x00\x00\x00'

---

Jusque là tout va bien.

Le seul truc un peu compliqué c'est que je veut modifier un peu mon output avant de l'écrire : je veux remplacer le 3 par 444.
Naïvement je fais

Code:

---

>>> struct.pack_into('I',output,struct.calcsize('II'),444 )

---

mais là, erreur, "Cannot use string as modifiable buffer" !

J'ai commencé à chercher, mais je ne trouve que des solutions à base de array. Et dans ce cas, pas moyen d'utiliser struct.pack...

De manière un peu plus générique, je veux :

- construire une string (ou n'importe quoi d'équivalant) par des concaténations successives avec struct.pack.
- modifier (de temps en temps) ma string déjà construite avec struct.pack_into.
- écrire le tout dans un fichier.
---> et bien sûr je ne connais pas la taille totale avant la fin...

Je ne peux pas croire qu'il n'existe pas un moyen simple et élégant de faire ça en python ! :calim2:

Tu es en Python 3 , non ?

Sous Python 2.7 , print output me sort des carrés.

Pour afficher la valeur de output, je suis obligé d’utiliser repr(output)






Puisque

Citation:

---

7.3 struct - Interpret strings as packed binary data

This module performs conversions between Python values and C structs represented as Python strings.

---

j’ai fait ça pour répondre à ton problème:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

import struct output = struct.pack( 'II',1,2 ) output += struct.pack( 'II',3,4 ) print repr(output)   def repl_in(out,x,y): I = struct.pack( 'I',x ) i = out.find(I) return out[:i] + struct.pack( 'I',y ) + out[i+len(I):]   output = repl_in(output,3,444) print repr(output)

---

Code:

---

1 2	'\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04\x00\x00\x00' '\x01\x00\x00\x00\x02\x00\x00\x00\xbc\x01\x00\x00\x04\x00\x00\x00'

---

Mais au vu de ce que tu veux faire:

Citation:

---

- construire une string (ou n'importe quoi d'équivalant) par des concaténations successives avec struct.pack.
- modifier (de temps en temps) ma string déjà construite
- écrire le tout dans un fichier.

---

je me demande si tu n’aurais pas intérêt à regarder du coté du module IO.

Il y a une classe class io.BufferedIOBase dont les instances sont des « binary streams that support some kind of buffering » qui peuvent être modifiées par des write()

Tu peux créer un "string buffer" à l'aide de la fonction make_string_buffer du module ctypes. Cela ne répond pas entièrement à tes besoins car il faut préciser la taille à la création, mais je doute que tu trouves exactement ce que tu cherches.

Code:

---

1 2 3 4 5 6 7 8 9 10

>>> from ctypes import create_string_buffer >>> b = create_string_buffer(8) >>> b <ctypes.c_char_Array_8 object at 0x02561210> >>> ''.join(x for x in b) '\x00\x00\x00\x00\x00\x00\x00\x00' >>> import struct >>> struct.pack_into('I',b,4,444) >>> ''.join(x for x in b) '\x00\x00\x00\x00\xbc\x01\x00\x00'

---

Bien sûr dans ce cas tu ne dois plus utiliser que struct.pack_into et plus du tout struct.pack.

[EDIT] Bon finalement, tu peux même utiliser le module array avec struct.pack_into:

Code:

---

1 2 3 4 5 6 7 8 9 10

>>> a = array.array('I',[1,2,3,4]) >>> a array('I', [1L, 2L, 3L, 4L]) >>> struct.pack_into('I',a,8,444) >>> a array('I', [1L, 2L, 444L, 4L]) # on peut même faire des trucs bizarres comme: >>> struct.pack_into('f',a,2,3.4) >>> a array('I', [2577006593L, 16473L, 444L, 4L])

---

Je plussoie dividee pour l'emploi de array pour l'écriture en binaire.
http://docs.python.org/library/array.html
Tes problèmes peuvent être résolus avec les méthodes pop et insert voir doc ci-dessus.
utilisation basique:

Code:

---

1 2 3 4 5 6 7 8 9 10

#!/usr/bin/env python import array data = array.array('B') data.append(ord('A')) data.append(ord('1')) data.append(int('11111111', 2)) # 255, 0xFF print data f = file('data.bin', 'wb') data.tofile(f) f.close()

---

j'utiliserai plutôt bytearray ... qui est built-in.
c'est mutable et ça se manipule comme un str et une liste combinés.
Suffit de taper dir(bytearray) pour se rendre compte de la puissance du truc :ccool:

Code:

---

1 2 3 4 5 6 7 8 9

output = bytearray('ma_chaine') output += bytearray('_plus_longue') str(output) # ==> 'ma_chaine_plus_longue' output = output.replace('plus','encore_plus') str(output) #==>'ma_chaine_encore_plus_longue' output[17:21]='+' str(output) #==>'ma_chaine_encore_+_longue' output.insert(18,43) str(output) #==> 'ma_chaine_encore_++_longue'

---

pour initialiser une liste de 10 octets ...

Code:

---

bytearray(10) # ==> bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')

---

Bref, on ne peut plus s'en passer ...
Le hic c'est que ça ne manipule que des octets :oops:

Citation:

---

Envoyé par sopsag

Je ne peux pas croire qu'il n'existe pas un moyen simple et élégant de faire ça en python ! :calim2:

---

y a un truc sympas en python qui permet de faire tout ce qu'on veut ... c'est le fait de pouvoir créer ses propres class. Quand tu ne trouves pas l'outil que tu veux, tu le fabriques :D

Citation:

---

Envoyé par josmiley

y a un truc sympas en python qui permet de faire tout ce qu'on veut ... c'est le fait de pouvoir créer ses propres class. Quand tu ne trouves pas l'outil que tu veux, tu le fabriques :D

---

Bien sûr !
C'est ce que je suis en train de faire...
J'écris le what-millième serialisateur de ma longue carrière de développeur !
Jusque là, je les écrivais en C ou en C++, mais je pensais le besoin tellement classique et récurrent que python m'en fournirait un déjà tout mâché dans une lib...
D'autant que la lib struct est vraiment très bien pensée.
Mais le fait qu'il faille choisir entre un append dynamique et accès aléatoire statique est vraiment dommage. D'autant plus que ce n'est qu'une limitation de l'API. Je pense qu'il n'y aurait aucune difficulté à ajouter la possibilité d'éditer ce qui a déjà été sérialisé.
C'est comme si les développeurs de cette lib n'avaient jamais pensé que ce besoin pourrait se présenter...
Pourtant le coup du "je sérialise des données puis je reviens au début pour indiquer leur taille" est très classique.

En tous cas, tu m'as convaincu d'utiliser les bytearray dans mon serialisateur... même si j'aimais bien la façon très élégante de gérer l'endiannesse de struct.

Je n'ai aucune théories informatique.

Si quelqu'un pouvait me donner une utilisation concrète du module struct, ça m'intéresserait pour ma culture :)

Quand je dis concrète, je parle aussi de son intérêt

Vous utilisez quelle version de Python ?
Moi Python 2.7, après avoir un temps utilisé 3.1

Or je n’ai pas trouvé bytearray() dans la Python Standard Library de la doc 2.7. , ni dans celle de la doc 2.6 : cette fonction n’est référencée ni dans leur chapitre “Built-in Functions“ ni dans leur chapitre “Non-essential Built-in Functions“

Pourtant

Citation:

---

Instances of the bytes type are immutable just as strings are. A new bytearray type stores a mutable sequence of bytes:

Byte arrays support most of the methods of string types, such as startswith()/endswith(), find()/rfind(), and some of the methods of lists, such as append(), pop(), and reverse().

There’s also a corresponding C API, with PyByteArray_FromObject, PyByteArray_FromStringAndSize, and various other functions.

http://docs.python.org/release/<font...tsnew/2.6.html

---

Les docs de 2.6 et 2.7 ont semble-t-il tout simplement oublié de référencer bytearray !
À moins qu’il y ait une raison obscure de ne pas pousser cette fonction sous les feux des projecteurs dans les versions 2.x




Merci donc à josmiley d’avoir amené cette fonction sur le tapis, sans ça je ne la remarquais pas avant de repasser à Python 3





Un bémol cependant:

un objet de type <type 'bytearray'> est une séquence de 8-bit bytes (soit dit en passant le nom octetarray() aurait été bien meilleur et éviterait bien des ambigüités qui existent aussi dans les notions impliquant Unicode)

Ce qui veut dire qu’on ne peut pas toujours représenter par un bytearrayde même longueur des chaînes comportant des caractères codés par des entiers supérieurs à 255, c’est à dire des caractères Unicode non-ASCII étendu

EDIT: ou plutôt il n’y a pas de bijection (pour parler avec la précision de Zavonen) entre les éléments d’une chaîne Unicode comportant des non-ASCII étendu et les éléments de sa transformée en bytearray.
Peut on dire que bytearray() sérialise une chaîne Unicode ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

x = bytearray('Haÿs') print x print list(x) print   uh = unichr(1009)+unichr(30823) print 'uh =',uh x = bytearray(uh,'utf_8') print 'bytearray(uh) =',x print 'str(bytearray(uh)) =',str(x) print 'list(bytearray(uh)) =',list(x) print   uuu = x.decode('utf-8') print uuu

---

uh qui comporte 2 caractères est transformée en un bytearray de 5 octets:
le premier caractère d’ ord() égal à 1009 donne deux octets 207, 177 et le deuxième caractère d’ ord() égal à 30823 donne trois octets 231, 161, 167.
Ceci , c’est avec encoding UTF-8. Car avec UCS-2, 30823 étant inférieur à 65536, le deuxième caractère est codable sur deux octets seulement. Mais UTF-8 ne fait pas la même chose que UCS-2.

decode() permet de revenir en arrière à partir d’un bytearray à condition d’indiquer un encoding.

x est un bytearray, mais on peut écrire print x et obtenir un affichage de caractères, sans devoir écrire print str(x) :
manifestement, l’instruction print fait un travail interprétatif, vraisemblablement c’est repr() qui est utilisée.







En fait, en Python 2.x,

- un objet de type str est une séquence de caractères codés sur des 8-bits bytes (= octets), c’est pourquoi on ne peut pas mélanger des chaînes de type unicode et des chaînes de type str.

- un objet de type bytearray est une séquence d’entiers codés sur 8-bit bytes aussi, on retrouve le même problème que pour les objets de type str, c’est normal.



NB:
j’emploie les termes str et unicode pour désigner les types en Python 2.x




Un objet de type bytearray est en entiers<256 (représenté par un octet)
ce qu’un objet de type str est en caractères ASCII étendu.
Soit dit en passant, en ASCII, les codes 0 à 31 et 127 sont des caractères de contrôle non imprimables. C’est pour ça que j’obtenais des carrés lors de print ouput avec output = struct.pack( 'II',1,2,3,4 )



Parallélement, je pense que la représentation interne des chaînes Unicode est en entiers<1 114 112 ( représentés sur 4 octets en UCS-4 [mais toutes les valeurs possibles sur 4 octets pas utilisées] ) ou <65535 ( représentés sur 2 octets en UCS-2) )
ce qu’un objet de type unicode est en caractères Unicode.

On dispose de bytearray() pour nous permettre de manipuler des objets bytearray d’entiers<256,
Mais on ne dispose pas d’un moyen d’accéder à la représentation interne des chaînes Unicode.
Ce qui à mon avis est une cause de trouble dans la compréhension de tout ce bazar.




Si mon expression “représentation interne des chaînes Unicode“ vous laisse une impression de flou, voilà à quoi je fais référence:

Citation:

---

Python 3.0 uses the concepts of text and (binary) data instead of Unicode strings and 8-bit strings. All text is Unicode; however encoded Unicode is represented as binary data.
http://docs.python.org/release/3.0/whatsnew/3.0.html

---

Citation:

---

Under the hood, Python represents Unicode strings as either 16- or 32-bit integers, depending on how the Python interpreter was compiled.
http://docs.python.org/howto/unicode.html

---

Il me semble qu’il manque le mot 'sequence':
Python represents Unicode strings as either 16- or 32-bit integers sequences




M’enfin, je suis pas sûr sûr sûr de tout ça....





PS: je vois que josmiley a aussi souligné le fait qu'un bytearray ne manipule que des octets.

Dans le passage de Python 2.x à Python 3.x:

- le type unicode de 2.x devient le type str de 3.x

- le type str de 2.x devient le type bytes de 3.x

- les types unicode et str de 2.x, qui dérivaient d’un même type basestring et pouvaient s’accorder un peu dans certains cas,
deviennent donc deux types str et bytes complétement distincts et non combinables sans transformations par encode() ou decode()
(unicode() n'existe plus en 3.x)

- à coté des types unicode et str de 2.x qui étaient des types de séquences de caractères,
il existait aussi le type bytearray qui était le type de séquences d’octets

Donc dans 3.x, le type bytes vient compléter ce qui était déjà présent dans 2.x sous la forme du type bytearray.





Mais !.... je me suis aperçu que :



- si on fait print help(bytes) et print help(str) dans Python 2.x on obtient exactement la même docu:

Citation:

---

Help on class str in module __builtin__:

class str(basestring)
| str(object) -> string
|
| Return a nice string representation of the object.
| If the argument is a string, the return value is the same object.
|
| Method resolution order:
| str
| basestring
| object
|
| Methods defined here:

etc etc.....

---

:!:


- et le code

Code:

---

1 2 3

x = bytes('cachoterie') print 'x =',x print 'type(x) =', type(x)

---

donne

Code:

---

1 2	x = cachoterie type(x) = <type 'str'>

---

alors qu'on ne trouve pas la fonction bytes() dans la docu de Python 2.x
:!:



Quel cachotier ce Guido van Rossum.

Le type bytes était déja présent dans Python 2.x en prévision de 3.x pour accueillir les 8-bit bytes qui étaient dans 2.x les éléments des séquences de caractères de type str et des éléments des séquences de type bytearray.



En fait le type str était déjà un type bytes, mais vicieusement, quand on faisait print ’A’ ou print ’armure’ , les bytes qui étaient la véritable représentation interne de ’A’ et ’armure’ étaient interprétés pour afficher des caractères et non pas des entiers.

Je parie que c’était repr() qui était systématiquement appelée par print et qui était réglée pour donner un affichage de chiffres pour un entier-chiffre (type int, long etc) et un affichage de caractère pour un entier-octet (type bytes = str). C’est en fait le type qui commandait la transformation opérée.



Vous me suivez ?
Moi j’ai du mal à ne pas m’y perdre à nouveau.
C’est pas sympa de la part des docs de ne pas avoir expliqué ça clairement.
Pas étonnant que les problèmes d’encodage aient toujours paru abscons.
Qu'est ce que vous en pensez ?

Salut

Citation:

---

C’est pas sympa de la part des docs de ne pas avoir expliqué ça clairement.
Pas étonnant que les problèmes d’encodage aient toujours paru abscons.
Qu'est ce que vous en pensez ?

---

Lorsqu'on décide de sortir une nouvelle fonctionnalité majeure çà prend 2/3 ans avant que cela puisse être livré. D'ici là, on a la possibilité de livrer des mises à jours de la version courante qui incluront les fonctionnalités dont les dépendances avec les nouveautés seront 'réduites' et celles qui aideront à effectuer la transition.

La transition concerne les fonctionnalités internes et les applications 'utilisateurs'. Lorsqu'il s'agit d'aider principalement la transition de fonctionnalités internes, pas la peine de passer du temps à documenter plus que nécessaire.

Si tu veux savoir la 'vérité', il devrait suffire d'aller fouiller dans les archives de la mailing list de python-dev.
- W

Bonjour,

Citation:

---

Envoyé par fred1599

Si quelqu'un pouvait me donner une utilisation concrète du module struct, ça m'intéresserait pour ma culture :)

Quand je dis concrète, je parle aussi de son intérêt

---

Voilà un exemple très concret: http://python.jpvweb.com/mesrecettes.../lecture_dbase. J'avais à lire les données de fichiers dbase III+, parce que le logiciel qui les gérait (écrit en Delphi BDE) n'avait pas de fonction d'exportation. Je me suis renseigné sur la structure binaire du fichier, et j'ai fait un module pour intégrer les données dans mes programmes Python. J'aurais pu aussi traiter la mise à jour de la même façon, mais la mise à jour des index est très compliquée.

Tyrtamos

Citation:

---

Lorsqu'il s'agit d'aider principalement la transition de fonctionnalités internes, pas la peine de passer du temps à documenter plus que nécessaire.

---

Ah bon, ah bon ?


GvR a écrit:

Citation:

---

As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text. To be prepared in Python 2.x, start using unicode for all unencoded text, and str for binary or encoded data only. Then the 2to3 tool will do most of the work for you.

http://docs.python.org/release/3.0/whatsnew/3.0.html

---

Il nous conseillerait donc de nous préparer sans nous donner tous les éléments de compréhension possible ?



Comme je trouve indispensable pour ma part de comprendre que le type str dans Python 2.x est en fait un type bytes !

J’avais lu plusieurs fois que les chaînes de caractères de type str étaient en fait des chaînes de bytes, et je ne comprenais pas vraiment ce que cela voulait dire.

caractères = cela désigne ce qu’on veut en voir lors d’un affichage, le résultat, et donc pour avoir ce résultat il faut qu’il y a une interprétation à un moment

et bytes = cela veut dire que cette interprétation interprète des bytes de 8 bits, donc qu’il y a exclusivement des octets à l’origine, et pas autre chose, d’où les problèmes de temps à autre avec des encodings mal maîtrisés.



Si on comprend la source de la rivière, alors on en comprend son flot, à mon sens.

bytearray est documenté là à Mutable sequences:
http://docs.python.org/release/2.6.5...type-hierarchy
avec un exemple indirect ici:
http://docs.python.org/library/stdty...emoryview-type
c'est vrai que c'est hyper-léger et c'est bien dommage.

Warf...

Citation:

---

Il nous conseillerait donc de nous préparer sans nous donner tous les éléments de compréhension possible ?

---

Comment définir ces éléments de compréhension? D'autant qu'ils bougent à mesure qu'on avance dans la réalisation de Python 3.x...

Citation:

---

Envoyé par eyquem

Si on comprend la source de la rivière, alors on en comprend son flot, à mon sens.

---

C'est un wicked problem
- W