pickle gibt convert error von string to float

[fretchen]

hallo, ich habe eine große liste.
diese lasse ich von einem programm mit picklen. dann rufe ich automatisch ein anderes programm auf welches dann diesen fehler ausgibt

raus.data
Traceback (most recent call last):
File "ber_script.py", line 6, in ?
angezeigt=pickle.load(f)
File "/usr/lib/python2.4/pickle.py", line 1390, in load
return Unpickler(file).load()
File "/usr/lib/python2.4/pickle.py", line 872, in load
dispatch[key](self)
File "/usr/lib/python2.4/pickle.py", line 968, in load_float
self.append(float(self.readline()[:-1]))
ValueError: invalid literal for float(): 0,01

ich habe in dem ursprungsprogramm dann natürlich geschaut ob es dort geht. hier entpickelt er aber ohne jeden anstand

nur kurz mal der code in dem programm welches den fehler verursacht

Code: Alles auswählen

import pickle as pickle
import pylab
name='raus.data'
f=file(name,'r')
print name
angezeigt=pickle.load(f)
f.close()

wenn jemand dieses problem kennt, wäre ich über hilfe echt begeistert, denn ich weiß nicht mehr was ich machen soll

[Bernhard]

> sorry, nicht richtig gelesen, deshalb post wieder gelöscht.

[Leonidas]

Kann es sein, dass das Programm die pickle-Daten in Textdateien speichert (es kann nämlich sein, das da irgendetwas an der pickle-Datei korrumiert ist)? Zum Schreiben der pickle-Daten sollte stets der Dateimodus 'wb' genutzt werden, denn das ursprüngliche pickle-Protokoll (Protokoll 0) sieht zwar wie Text aus, ist es aber (so weit ich weiß) nicht.

[fretchen]

also ich speichere die datei als *.data ab und auch mit dem wb-modus existiert weiterhin exakt der gleiche fehler.

hier ist nochmal der picklecode dazu

Code: Alles auswählen

gezeigtes=self.uebersicht.gezeigt[:]
print type(gezeigtes)
name='raus.data'
f=file(name, 'wb')
pickle.dump(gezeigtes, f)
f.close()

und wie gesagt gezeigt ist ne ne recht große liste. könnte es irgendwie an den typen in der liste hängen? eigentlich doch nicht oder?

[sunmountain]

Du hast ein 0,01 "gepickelt", also ein String.
Den versucht Pickel, warum auch immer, als Float zu interpretieren,
das geht in die Hose.

Anderes Beipiel:

Code: Alles auswählen

f = float('3,1415926')
print f

führt zur selben Fehlermeldung:

Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): 3,1415926

Ein Float hat in Python den Punkt als Dezimaltrenner, das Komma
dient für Aufzählungen (Listen, Tuple etc.)

[fretchen]

puh, danke

das heißt ich habe voor 3monaten oder so nen fehler gemacht:(

das heißt viel viel arbeit
ich poste dann mal die lösung, wenn ich sie denn finde

[cracki]

was hast du gemacht?

pickle speichert strings auch nur als strings, gleiches mit floats. so ein fehler kann garnicht passieren, wenn du pickle richtig benutzt.

hast du die datei selber erstellt?

biete doch mal einen testcode an, der das problem reproduziert.

[sunmountain]

Hast Du vielleicht Deinen eigenen Pickler geschrieben ?
Man kann versucht sein, das zu tun, das Protokoll ist sehr einfach.
Ansonsten wüßte ich auch nicht, wie es dazu kommen soll.

Beispiel:

Code: Alles auswählen

import sys
import pickle

p = pickle.Pickler(sys.stdout)
p.dump(3.1415926)

# Geht, druckt sowas wie F3.1415926\n.

# Nun umgekehrt

f = open('float.dat','w')
print >>f,'F3,1415926\n.',
f.close()
u = pickle.Unpickler(open('float.dat'))
u.load()

# Geht nicht ...

>>> u.load()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Python23\lib\pickle.py", line 872, in load
dispatch[key](self)
File "C:\Python23\lib\pickle.py", line 968, in load_float
self.append(float(self.readline()[:-1]))
ValueError: invalid literal for float(): 3,1415926

Das Pickle Protokoll ist im Übrigen einfacher Text (genauer, Protokoll 0); ein 'wb' oder 'rb' beim
Öffnen der Datei sorgt nur dafür, das die Daten binär, also ohne Interpretation der platformspezifischen Eigenarten ('\n' vs. '\r\n') geschrieben oder gelesen werden. Das ist aber nur wichtig, wenn
das selbe Pickle-File z.B. von Windows nach Linux und vice-versa
gehen soll.

Siehe auch : http://docs.python.org/lib/node316.html bzw.
http://www.python.org/dev/peps/pep-0307/

Helfen wird Dir beim Bereinigen der Dateien der gute alte sed oder vi

[fretchen]

ich habe kein pickleprotokoll geschrieben aber ich habe eine vermutung, wenn ich das problem gefunden habe, dann schreibe ich es.

wenn es nicht so ist, dann werde ich mal fehlercode angeben

[jens]

Code: Alles auswählen

f = open('float.dat','w')
print >>f,'F3,1415926\n.',

Was denn das für ein print?

[BlackJack]

Das ``print`` wird in die Datei `f` umgeleitet. Eine der komischen Besonderheiten die Guido heute bereut, weil sie die Syntax unnötig kompliziert machen.

[Leonidas]

Das ``print`` wird in die Datei `f` umgeleitet.

Kann übrigens auch jedes andere file-like-object sein, wie StringIO oder sys.stdout.

[jens]

Die Syntax hab ich bisher noch nie gesehen und werde die auch am besten gleich wieder vergessen

Ist es wenigstens als deprecated bezeichnet?

[BlackJack]

Es wird zusammen mit ``print`` als Anweisung in Python 3000 verschwinden.

[name]

aehm, python verwendet . als kommazeichen, vllt liegts ja daran, hab das immer falsch und mit , gelesen in dem post

[sape]

Das ``print`` wird in die Datei `f` umgeleitet.

Kann übrigens auch jedes andere file-like-object sein, wie StringIO oder sys.stdout.

Und alle anderen die ``>>`` überladen haben.

Code: Alles auswählen

[...]
self.txt_ctrl = wx.TextCtrl(self.panel, style=wx.TE_MULTILINE)
[...]
print >> self.txt_ctrl, "foobar"
[...]

anstatt, das man das so schreibt.

Code: Alles auswählen

self.txt_ctrl.AppendText("foobar")

Ich finde es praktisch. Ist gegen die Benutzung was auszusetzen und sollte ich mir das wider schnell abgewöhnen Hmm, ich finde nicht das es die Syntax verkompliziert.

lg

[BlackJack]

Das ``print`` wird in die Datei `f` umgeleitet.

Kann übrigens auch jedes andere file-like-object sein, wie StringIO oder sys.stdout.

Und alle anderen die ``>>`` überladen haben.

Nein! Das hat mit dem binären ``>>``-Operator überhaupt nichts zu tun, das ist ein Sonderfall…

Hmm, ich finde nicht das es die Syntax verkompliziert.

…und weil es ein Sonderfall ist, macht es die Syntax komplizierter. Ein Spezialfall, den man sich merken muss.

[sape]

Danke für die Info. Werde es dann auch nicht mehr benutzen.

lg

[birkenfeld]

Danke für die Info. Werde es dann auch nicht mehr benutzen.

Wieso nicht?

[sape]

Wieso nicht?

Ich versuche die Sachen die als schlecht in Python angesehen werden, zu vermeiden. Erstmal weil ich schönen Code schreiben will den auch andere schön und brauchbar finden. Zweitens kann es ja mal sein das ich mich einem Projekt anschließe und dann sollte man sich ja schon größtenteils an PEP8 halten und Sachen vermeiden die nicht als gut angesehen werden.

Außerdem wenn es ehe in Py3K wegkommt, benutze ich das dann lieber ehe nicht, da ich in diesen Fall darauf auch verzichten kann und beim umstieg weniger umschreiben muss. -- Aber eine Begründung wollte ich dennoch vorher gerne gehabt habe, die ich nun habe.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen (wenn man es nicht für den eigentlichen Einsatzzweck den bitshifting nutzt)?

lg