Ansi-Projekte nach Unicode konvertieren

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.
Antworten
HarryH
User
Beiträge: 266
Registriert: Freitag 23. Mai 2003, 09:08
Wohnort: Deutschland

Hallo,

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: Py 3.x betreffend: Sonstige: 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.
Gruß, Harry
BlackJack

@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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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
HarryH
User
Beiträge: 266
Registriert: Freitag 23. Mai 2003, 09:08
Wohnort: Deutschland

@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?
Gruß, Harry
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

Was mir in letzter Zeit immer mal wieder in die Quere kommt:

Code: Alles auswählen

'T{}te'.format(u'ü') # geht nicht
u'T{}te'.format(u'ü') # geht
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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
HarryH
User
Beiträge: 266
Registriert: Freitag 23. Mai 2003, 09:08
Wohnort: Deutschland

Leonidas hat geschrieben: :?: Von was von Dingen sprichst du?
Weiß ich selber nicht :D
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:

Code: Alles auswählen

from __future__ import division, unicode_literals, print_function
Gruß, Harry
Antworten