Ausfürliche Definition der pickle Protokolle

[DasIch]

JSON ist gar keine so dumme Idee aber knapp vorbei ist auch vorbei.

Code: Alles auswählen

>> import yaml
>> a = [1, 2]
>> b = [a, a]
>> b
 > [[1, 2], [1, 2]]
>> c = yaml.load(yaml.dump(b))
>> c
 > [[1, 2], [1, 2]]
>> c[0][1] = 42
>> c
 > [[1, 42], [1, 42]]
>> print yaml.dump(b)
- &id001 [1, 2]
- *id001

[sma]

Es hat ungefähr 15 Minuten gedauert, einen eigenen Serializer zu bauen, der so einfach ist, dass man sicherlich auch ein PHP-Gegenstück bauen kann und der dies kann:

Code: Alles auswählen

>>> d = {1: "zwei", 3: [True]}; d[3].append(d)
>>> Serializer().write(d)
"{(I1S'zwei';(I3[TR0;;;"

Das { steht für dict, ( für tuple, I für int und S für str. Danach kommen jeweils die Daten. Sequenzen werden mit ; beendet. Das R ist eine Referenz, damit rekursive Datenstrukturen funktionieren. Der Encoder hat 21 Zeilen, der Decoder 26.

http://gist.github.com/151889

Stefan

[birkenfeld]

Sieht nett aus!

Zwei Anmerkungen: Strings mit Single-Quotes und negative Integers mag das Ding nicht, und das Slicing von m.group() könnte man vermeiden, wenn man die Gruppen in der Regex auf den eigentlichen Wert einschränkt. Ach ja, und es dürfte schneller sein, den String nicht nach jedem Match zu slicen, sondern einfach einen Startindex i zu inkrementieren und ihn re.match mitzugeben (dafür braucht es aber ein regex-Objekt).

[sma]

Hatte nicht bedacht, dass `repr()`von ' auf " wechselt, wenn ein ' im String vorkommt. Das und negative Zahlen werden jetzt erkannt. Für Strings ist der reguläre Ausdruck allerdings immer noch zu trivial, denn er erkennt keine \. Das überlasse ich dem Leser als Übung.

Ansonsten habe ich nach birkenfelds Blick den Code nochmals geändert, weil mir doch 40 Zeilen für den Decoder einfach zu viel waren. Auf Effizienz hatte ich zwar überhaupt nicht geachtet, aber ich denke, das neue Verfahren würde besser performen, wenn einem das wichtig wäre.

Stefan

[birkenfeld]

LOC durch 1-Zeilen-Suiten zu sparen, ist natürlich keine Kunst

[str1442]

Sind True und False in 3.0 nun genau wie None "Singletons"? Nachdem ich den Quelltext von sma gesehen hatte, habe ich in den What's new Dokumenten + Language Reference nachgeschlagen, habe aber nur herausgefunden, das beide nun wie None "reservierte Wörter" geworden sind.

[Leonidas]

Sind True und False in 3.0 nun genau wie None "Singletons"?

Ja, sind sie. Siehe ``help(bool)`` (aber das waren sie auch schon vorher, mindestens seit Python 2.5).

[Defnull]

Ansonsten habe ich nach birkenfelds Blick den Code nochmals geändert, weil mir doch 40 Zeilen für den Decoder einfach zu viel waren.

Genau DAS mag ich an sma

[birkenfeld]

Sind True und False in 3.0 nun genau wie None "Singletons"?

Ja, sind sie. Siehe ``help(bool)`` (aber das waren sie auch schon vorher, mindestens seit Python 2.5).

Schon seit sie in Python 2.2.x eingeführt wurden.

[str1442]

Das auch schon in 2.5 (und wie ich ja gerade gelesen habe, auch darunter) von beiden nur ein Exemplar existiert, wußte ich bereits, aber meine Frage war eher darauf gerichtet, ob das ein Implementierungsdetail ist oder nicht, ähnlich wie bei allen int Objekten unter einer bestimmten Grenze (ich glaube es war 256?), die ja auch gecacht werden, obwohl dieses Verhalten von CPython eben ein Implementierungsdetail ist. Sollte es also keins sein, mag es sein, das ich aufgrund der "reservierte Wörter" Geschichte, dem Cachen von normalen Integern und alten Postings aus dem Forum annahm, es wäre eins (Meine Güte, heute baue ich wieder wundervolle Sätze ).

tl;dr: Da es in der Dokumentation für Bool steht, ist das also garantiert - Danke