nicht angemeldet
echo $begrüßung;
Das selbe passiert, wenn du print repr(a) eingibst. Wenn du eine komplexe Struktur ausgeben willst, wird sie offensichtlich in der von repr() gelieferten Darstellung ausgegeben.
Ja, das kann gut sein. Aber warum nur bei komplexen Strukturen und nicht bei einem einzelnen String?
Beim Ausgeben von Strings erwartet man eine "normale" Darstellung. Komplexe Strukturen sind zum Datenspeichern gedacht und nicht zum Ausgaben am Bildschirm. Dass du da eine Darstellung bekommst, dient zu Kontrollzwecken. Du bekommst da ja auch Zeichen wie ,[]{} usw. angezeigt, die zur Syntax und nicht zu den Daten gehören. Du könntest genauso gut gegen diese opponieren. Wenn du eine andere als die Standard-Ausgabe haben möchtest, kannst du das bei Python ja wenigstens durch überschreiben der __Funktionen__ tun. Andere Systeme sind da eingeschränkter.
Okay, aber wozu gibt es dann das u bzw. U vor dem String? Der Python-Interpreter merkt es doch sowieso, wenn ein String Nicht-ASCII-Zeichen enthält.
Auch Python war nicht von Anfang an Unicode-fähig. Die herkömmlichen Strings arbeiten nach dem Ein-Zeichen-ein-Byte-Prinzip und sind damit den üblichen Einschränkungen unterworfen. Auf Mehrbyte-Kodierungen umzusteigen ist nicht so einfach. Da wollen jede Menge Nebenwirkungen beachtet werden. Deshalb hat man wohl auch die Unicode-Strings als Zusatz eingebaut.
Wenn die interne Darstellung "sein kann wie sie will", dann brauche ich die Kodierung doch tatsächlich erst zum Zeitpunkt der Ausgabe festzulegen, und nicht schon beim Erstellen des Strings.
Das setzt voraus, dass Python intern komplett fähig wäre, um bei der Ausgabe sämtliche Kodierungen bedienen zu können. Sprich: Es dürfen bei der internen Verarbeitung keine Zeichen unberücksichtigt bleiben. Das Ein-Zeichen-ein-Byte-Prinzip kann jedoch nur 256 Zeichen berücksichtigen und ist aus historischen Gründen noch vorhanden. Irgendwie muss man nun unterscheiden, welches der beiden Systeme man haben möchte. Die neueren Unicode-Strings bekamen deshalb zur Kennzeichnung das u. Bei Python 3 wird das anders werden. Bis dahin musst du mit den zwei Systemen leben. (http://docs.python.org/dev/3.0/whatsnew/3.0.html#strings-and-bytes)
Den Default-Wert der Ausgabekodierung [...]
Bei mir kommt da: 'ascii'.a = 'ähnlich'
print a
ähnlich
Was passiert hier? Müsste nicht mit einer Fehlermeldung abgebrochen werden, da der vermeintliche ASCII-String ein Zeichen enthält, das im ASCII-Zeichenvorrat doch gar nicht vorkommt?
Wieso kann Python mit der Ausgabekodierung ASCII, die ich nirgendwo beeinflusst oder geändert habe, einen Nicht-ASCII-String ausgeben?
Die Antworten muss ich dir schuldig bleiben. Damit habe ich mich nicht weiter beschäftigt. Ich nehm nur UTF-8. Auch einen kurzen Rechercheversuch konnte ich nicht erfolgreich beenden.
Setzen geht beispielsweise in einer Datei namens sitecustomize.py. Liegen kann sie wohl an mehreren Stellen. Bei mir liegt sie unter /usr/lib/python2.5/site-packages/.
Das Verzeichnis gibt es bei mir auch, die Datei aber nicht.
Die ist zum Anlegen bei Bedarf gedacht. Du kannst ja mal recherchieren, wo sie überall liegen darf. Nicht immer will man das komplette System umstellen. Deswegen gibt es auch die anderen Stellen.
Gute Idee, __str__ zu überschreiben, auch wenn ich das Verhalten von Python in diesem Punkt inkonsistent und unpraktisch finde - solche "Kunstgriffe" sollten IMHO gar nicht nötig sein.
Bei verschiedenen Anwendungsfällen ist es durchaus nicht unüblich verschiedene Verhaltensweisen zu verwenden. Ebensogut könntest du meinen, dass bei einer Ausgabe von Typen (print bool) und Objekten eine andere als die derzeitige Darstellung konsistenter wäre. Konsistent gegenüber welchem (vorwiegend üblichem) Anwendungsfall?
echo "$verabschiedung $name";