Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Ich habe vor meine Ansi-Projekte (Packages, Module, Scripts ...) auf Unicode umzustellen.
Doch erweist sich dies meiner Meinung nach doch nicht so trivial wie anfangs gedacht. Ich denke mal, dass da auch viel Handarbeit nötig sein wird.
Meine Ziel/Wunsch dabei:
Lauffähig in Python 2.7
Verwendung von wxPython unicode
Verwendung von pywin32
Die Anpassungen (Unicode betreffend) sollen auch eine unkomplizierte zukünftige Umstellung auf Py3 ermöglichen
Also habe ich mir diverse Infos gegoogelt und erarbeitet. Py 2.x und wxPython betreffend:
Folgende Punkte meine ich nun modifizieren zu müssen:
Alle nicht ASCII-konformen Zeichenketten innerhalb des Scripts als Unicode deklarieren (u'')
Daten beim Import/Input nach Unicode wandeln; betroffene Operationen anpassen:
sys.stdin.read
file inputs
sys.argv
Usereingaben wie z.b. raw_input
Daten beim Export/Output kodieren, z.B. an das Filesystem anpassen (mit sys.stdout.encoding or sys.getfilesystemencoding()); betroffene Operationen adaptieren:
sys.stdin.write, sys.stderr.write
file outputs
print
wxPython Default-Encoding (wx.SetDefaultPyEncoding("utf-8")) setzen; für den Fall das mal eine Unicode Deklaration übersehen wurde. Das Default-Encoding muss dem Script-Encoding entsprechen.
Zu weiteren Punkten habe ich noch Fragen; dabei ist mir noch einiges unklar.
Sollte man str() in Unicode-Programmen überhaupt noch verwenden (beispielweise bei der Umwandlung von int -> str)? Oder am besten gleich unicode()?
Wie steht's mit pickle? Kann man gepickelte Daten aus einer Ansi-Version problemlos mit einer Unicode-Version öffnen? Oder wird beim pickle'n das Encoding mitgespeichert?
Ist es sinnvoll, auch in Anbetracht von Py3, alle Python-Scripts's nach UTF-8 zu konvertieren und dies dann in der Encoding line (# -*- coding: utf-8 -*-) entsprechend zu bezeichnen? Habe ich dann weniger Probleme, bzw. Aufwand bei Funktionen wie str(), format() und %-formatting?
Wie sieht's mit _winreg aus, also dem Zugriff auf die Windows Registry? Ist es dort genauso wie bei z.B. os.listdir(), dass wenn in Unicode übergeben wird, dies auch wieder zurückkommt, etc. ?
Bei pywin32 die Unicode-Funktionen verwenden?
Ich hoffe ihr könnt mir bei meinem Problem weiterhelfen und die Infos/Vorschläge/Verbesserungen können dann auch anderen zugute kommen, die vor denselben/ähnlichen Herausforderungen stehen.
Ich bin offen für Anregungen und Kritik.
Zuletzt geändert von HarryH am Montag 6. Dezember 2010, 16:39, insgesamt 1-mal geändert.
@HarryH: `pickle` speichert Objekte. Wenn Du `unicode`-Objekte picklest, bekommst Du beim entpicklen auch wieder `unicode`-Objekte. Genauso bei `str`-Objekten. Da irgendwo die Kodierung mit zu speichern macht keinen Sinn, weil weder `unicode` noch `str` Objekte etwas von Kodierungen wissen.
Es ist sinnvoll in allen Quelltextdateien, die Zeichen ausserhalb des ASCII-Wertebereichs enthalten, den Kodierungskommentar anzugeben. Der muss zur tatsächlichen Kodierung passen -- das ist das Einzige was wirklich wichtig ist. UTF-8 macht IMHO nicht speziell im Hinblick auf Python 3 Sinn, sondern generell, weil man damit den kompletten Unicode-Bereich abdecken kann.
HarryH hat geschrieben:Alle nicht ASCII-konformen Zeichenketten innerhalb des Scripts als Unicode deklarieren (u'')
Du kannst stattdessen auf den __future__-Import verwenden. Wenn du eh nur mit 2.6+ kompatibel bleiben musst scheint mir das im Hinblick auf eine Portierung sinnvoller.
HarryH hat geschrieben:Ist es sinnvoll, auch in Anbetracht von Py3, alle Python-Scripts's nach UTF-8 zu konvertieren und dies dann in der Encoding line (# -*- coding: utf-8 -*-) entsprechend zu bezeichnen? Habe ich dann weniger Probleme, bzw. Aufwand bei Funktionen wie str(), format() und %-formatting?
UTF-8 ist sowieso sinnvoll, unabhängig von Unicode im Programm.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@Leonidas
Meinst du damit, dass durch den __future__-Import alle im Script ausgezeichneten Zeichenketten grundsätzlich als Unicode interpretiert werden, so wie in Py3 ?
Ich frage mich an dieser Stelle allerdings, ob es da nicht zu Komplikationen mit wxPython kommen könnte, da ja auch andere Dinge durch den __future__-Import importiert werden?
HarryH hat geschrieben:Meinst du damit, dass durch den __future__-Import alle im Script ausgezeichneten Zeichenketten grundsätzlich als Unicode interpretiert werden, so wie in Py3 ?
Nur die im aktuellen Modul.
HarryH hat geschrieben:Ich frage mich an dieser Stelle allerdings, ob es da nicht zu Komplikationen mit wxPython kommen könnte, da ja auch andere Dinge durch den __future__-Import importiert werden?
Von was von Dingen sprichst du?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Leonidas hat geschrieben:
Von was von Dingen sprichst du?
Weiß ich selber nicht
Ich schrieb 'Dinge' weil ich ehrlich gesagt nicht wußte, was dieses Modul tatsächlich alles so macht und mir folglich keine genauere Definition einfiel. Und da es noch keine wxPython-Version für Py3 gibt, wollte ich damit einfach eine Befürchtung äußern, es könnte mit wxPython-Versionen für Py2.x Ärger geben.
Nach einem kurzem Überflug über die Doku ist mir aber nun klar, dass in Py2.7 nicht mehr aktiviert/importiert werden kann, als in folgender Zeile: