[Python-de] Unicode - ein Vorschlag zur Güte

Gerson Kurz Gerson.Kurz at t-online.de
Mon Dez 29 18:51:23 CET 2003


Da wir hier mal wieder ein Unicodeproblem haben, möchte ich schamlos auf
einen meiner unzähligen Ergüsse hinweisen:

http://p-nand-q.com/python/unicode_faq.html

und die Gelegenheit nutzen, nochmals gegen Windmühlen anzurennen.

Vorneweg: Unicode ist die "richtigere" Art, in Programmen mit Text
umzugehen. All die Unterscheidungen zwischen "ASCII", "Bytestrings" und
"UNICODE" sind vollkommen berechtigt.

Das ist alles ganz richtig, das gebe ich alles zu. Damit habe ich kein
Problem, ok? Du hast vollkommen recht! Niemand wiederspricht dir!
HALLELUJAH!

Es geht vielleicht um etwas ganz anderes: immer wieder laufen Leute in
Probleme, da in Python Fehler in der Unicode-Text-Behandlung sofort zu
Exceptions (und damit in der Regel zu einem Programmstop) führen. Diese
Fehler treten nach Murphy natürlich immer dann auf, wenn man sie gerade
nicht brauchen kann, und zwar zu 95% nach dem Abnahmetest.

Da sagt die "Wir-haben-richtig"-Fraktion: Siehst du, hast du Fehler, musst
du ausbessern, ist besser so!

Das alles mag schon sein, aber das ist die falsche Zielsetzung: es geht
nicht darum, ein ästhetisches Ziel zu erreichen (das "fehlerfreie" Programm,
ein Konzept mit höchstens einer Handvoll Instanzen - "tex" z.B) sondern ein
praktisches Ziel (z.B. ein Gerät anzusteuern in meinem Fall). Und da gibt es
ein so altes Konzept wie die Relevanzabschätzung: wie relevant ist das
Problem, wenn in z.B. einem Logfile ein ü ein ? ist? Genau: komplett
irrelevant.

Extrembeispiel: Wenn du auf der Autobahn deinen Todestrieb auslebst,
möchtest du auch nicht, daß der Bremscomputer plötzlich einen Stunt hinlegt,
weil "eine schwere Ausnahmebedingung aufgetreten ist". Nein, du willst daß
er abschätzt: was ist wichtiger, behandle ich einen schimmligen Umlaut, oder
erzeuge ich eine schimmlige Leiche?

Deshalb ist es mein Vorschlag, einen Parameter einzuführen, der eine
relaxtere Behandlung von Unicodeproblemen ermöglicht (angefangen mit der von
der Wahrheitsfront hoch gepriesenen Entscheidung für 7-Bit-ASCII). Sag mir
keiner, daß das nicht möglich ist - C kann es seit ca. 250 Jahren, oder?

Nochmal, ich wiederhole das eingangs gesagte: es ist schon DER RICHTIGE WEG
ZUM GLÜCK (TM), entsprechende Umlaut-Fehler zu bereinigen - es ist nur
häufig völlig unangemessener Aufwand verglichen mit dem tatsächlichen Ziel
des Menschen, der da was hinschreibt. Wenn ich ein Logfile analysiere,
brauche ich wirklich KEINE WARNING NACH STDERR, weil ich in einem KOMMENTAR
(um himmels willen!) einen Umlaut habe (und ja, ich schreie dies). Für eine
nicht leere Menge an Problemen ist es mir völlig wurscht, ob das ü als ?
erscheint - das bin ich als jahrelanger FreeAgent aus dem Usenet eh gewohnt
;)

Da sind wir dann bei der alten Geschichte mit den Exceptions & den
Fehlercodes - nennt mich Hanswurst, aber es gibt Fehler, die man ignorieren
KANN. (Es gibt sogar Fehler, die man ignorieren SOLLTE, wie jede
nichttriviale zwischenmenschliche Beziehung dich lehren wird).

Um ein Beispiel aus der Physik zu gebrauchen: eine Quantenmechanische
Betrachtung ist auch richtiger, "näher an der Wahrheit dran" als eine in der
klassischen Mechanik ala Newton. Trotzdem kann man in einen Baumarkt gehen &
einen Hammer erstehen & damit wehrlose Nägel erschlagen, ohne zuvor komplexe
Berechnungen über Wahrscheinlichkeitsverteilungen, abgesehen solche
volkswirtschaftlicher Art betreffs des Geldbeutelinhalts, erstellt zu haben.

Unicode ist das eine Gebiet in Python, wo die Sprache von ihrer
pragmatischen Handhabung "als richtig erwiesener Konzepte" abweicht (anders
als z.B. in der Handhabung der "Objektorientierung", anders als die nicht
minder frustrierende Java-Alles-Ist-Eine-Klasse-Wozu-Gibt-Es-Static-Schule)

Nix für ungut,
Gerson

ps. Noch was fällt mir dazu ein: Wie wäre es, wenn Python verlangen würde,
daß der Programmierer neben dem Programm auch einen mathematischen Beweis
seiner Richtigkeit ablieferte? (Sowas ähnliches wurde ja vor 30-20 Jahren
mal angestrebt). Per Definition würde das die Qualität der Python-Programme
verbessern - und doch will das doch (hoffentlich) kein Mensch. Warum nur?
Wollen die alle schlechte Programme haben?