[Python-de] Merkwuerdiges bei "umlaut".upper()

[Dinu Gherman]

Hallo,

oehm... aehm... irgendwie darf das doch wohl nicht sein, dass die
String-
Methode upper() kleine Umlaute unverändert laesst, egal ob Byte-Strings
oder Unicode-Strings, egal ob auf Mac OS X oder Windows (Debian Linux
an-
scheinend genauso)? Im Beispiel unten kommt nur bei Unicode unter
Windows
das Ergebnis, das ich erwarte. Muss man dazu vielleicht schon im Modul
locale etwas einstellen?

In allen Beispielen wird ein kleines "oe" verwendet (nur, falls die
Email-
Programme das unterwegs verhunzen... Unter Mac OS X (10.3.9) habe ich
ein
normales Terminal-Fenster benutzt und unter Windows XP eine normale DOS-
aehnliche Konsole... lower() bzw. andere Umlaute habe ich nicht
getestet.
Scheint aber mit frz. Vokalen mit Accents das Gleiche zu sein.

Leicht irritiert,

Dinu


Python 2.4 (#1, Feb 7 2005, 21:41:21)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

"ö"

'\xc3\xb6'

print "ö"

ö

print "ö".upper()

ö

"ö" == "ö".upper()

True

u"ö" == u"ö".upper()

True


Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

"ö"

'\x94'

print "ö"

ö

print "ö".upper()

ö

"ö" == "ö".upper()

True

u"ö" == u"ö".upper()

False

[Uwe Schmitt]

-----Ursprüngliche Nachricht-----
Gesendet: Montag, 23. Mai 2005 15:33
Betreff: [mailinglist] [Python-de] Merkwuerdiges bei "umlaut".upper()

Versuch mal folgendes:

a = u"äöü"
print a
print a.upper()

Gruß, Uwe

[Berthold Höllmann]

Post by Uwe Schmitt

-----Ursprüngliche Nachricht-----
Gesendet: Montag, 23. Mai 2005 15:33
Betreff: [mailinglist] [Python-de] Merkwuerdiges bei "umlaut".upper()

a = u"äöü"
print a
print a.upper()

oder

.>>> print (u"äöü").upper()
ÄÖÜ

Gruß, Berthold

[Detlef Lannert]

Hallo Dinu,

Post by Dinu Gherman
oehm... aehm... irgendwie darf das doch wohl nicht sein, dass die
String-
Methode upper() kleine Umlaute unverändert laesst, egal ob Byte-Strings
oder Unicode-Strings, egal ob auf Mac OS X oder Windows (Debian Linux
an-
scheinend genauso)?

Was hast Du für Sprach-/Codeeinstellungen? Eventuell verändert kreatives
Experimentieren das Ergebnis, insbes. mit den Umgebungsvariablen LANG und
LC_CTYPE -- oder wie man das unter Win bzw. MacOS macht ...

det2:~/python/cvs/python$ echo $LANG
***@euro
det2:~/python/cvs/python$ python
Python 2.3.5 (#2, May 4 2005, 08:51:39)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Post by Dinu Gherman

u"ö" == u"ö".upper()

False

Post by Dinu Gherman

import locale
"ö", "ö".upper()

('\xf6', '\xd6')
Detlef

["Martin v. Löwis"]

u"ö" == u"ö".upper()

True

Probier' hier mal

repr(u"ö")

u"ö" == u"ö".upper()

False

Liefert doch was anderes, oder?

Vorsicht mit Nicht-ASCII-Zeichen im interaktiven Modus. Unter OSX
gibt es in Terminal.app keine Möglichkeit herauszubekommen, welches
encoding das Terminal gerade verwendet, deshalb kann Python das
auch nicht wissen. Ich hoffe (schwach) dass das in 10.4 verbessert
wurde (glaube aber eigentlich nicht dran).

Ciao,
Martin

[Dinu Gherman]

Post by "Martin v. Löwis"
Vorsicht mit Nicht-ASCII-Zeichen im interaktiven Modus. Unter OSX
gibt es in Terminal.app keine Möglichkeit herauszubekommen, welches
encoding das Terminal gerade verwendet, deshalb kann Python das
auch nicht wissen. Ich hoffe (schwach) dass das in 10.4 verbessert
wurde (glaube aber eigentlich nicht dran).

Eine kleine Abschweifung zu dem Thema gefaelligst, das mir eine fast
schlaflose Nacht bereitete...? Also gut...

Das ist vermutlich ein Teil des Problems. Ich hatte mich schon ge-
wundert, warum meine Terminal-Eingaben anscheinend in UTF-8 waren.
Tatsache ist, die Standard-Codierung findet man sehr wohl heraus,
die steht in ~/Library/Preferences/com.apple.Terminal.plist, leider
als Aufzaehlungstyp, fuer den ich die Nummerierung noch nicht heraus
habe, aber folgende Zeilen gelten fuer UTF-8:

<key>StringEncoding</key>
<string>4</string>

Kniffliger wird es, wenn man fuer ein bestimmtes, geoeffnetes Fen-
ster eine solche Einstellung aendert. Dann kann ein Programm wohl
wirklich nur per AppleScript an die Einstellungen kommen. Leider
kenne ich mich damit zu wenig aus und habe im Internet kaum brauch-
bare Dokumente gefunden, wie man allgemein herausfindet, wie die
AppleScript-Schnittstelle einer Anwendung aussieht bzw. die Abbil-
dung ihrer Systemeinstellungen auf AppleScript-Bezeichner. Hier
nur ein sehr einfaches Beispiel zum Setzen der Textfarbe im vor-
dersten Fenster (sieht merkwuerdig aus, geht aber:

osascript -e 'tell application "Terminal" to tell its front window
to set its normal text color to "blue"'

Eigene Nachforschungen in den Anwendungsordnern (.app) unter OS X
foerderten bei mir die Einsicht zu Tage, dass es darin Dateien gibt,
die beschreiben, was die Anwendung AppleScript-seitig so kann. Nur
ist Terminal.app, jedenfalls unter 10.3 da relativ schwach und kann
nur Fenster-, aber keine Textattribute lesen/setzen, wie man hier
sieht:

osascript -e 'tell window 1 of app "Terminal" to get its properties'

, number of rows:16, bold text color:black, processes:login, bash,
tcsh, osascript, cursor color:21823, 21823, 21823, frame:35, 465, 743,
252, size:743, 252, busy:true, title displays window size:true,
origin:35, 465, frontmost:true, zoomed:false, miniaturized:false,
name:Terminal ? osascript ? 120x16, floating:false, modal:false,
miniaturizable:true, visible:true, closeable:true, resizable:true,
zoomable:true, id:14764, titled:false, index:1, class:window

Lustigerweise kommt man zwar auch an den Fensterinhalt heran, naemlich
mit:

osascript -e 'tell window 1 of app "Terminal" to get its contents'

aber anscheinend nur fuer "andere" Fenster (mit window 2, etc) und/oder
nur mit dem Programm Script Editor.app...

Irgendwie ist das alles ziemlich Voodoo-maessig... Und ich habe keine
Ahnung, ob das unter 10.4 (Tiger) anders/besser ist... Ich glaube, die
Umgebungsvariablen wie LANG werden von Terminal.app voellig ignoriert.
Ach ja, wenigstens scheint die Sonne ein bischen...

Ja, man koennte auch die Standardeinstellungen im Hintergrund temporaer
andern und ein neues Fenster aufmachen... Vielleicht geht ja wenigstens
so etwas mit AppleScript. Wer sich das nur ausgedacht hat, eine Art Pro-
grammiersprache fuer Nicht-Programmierer...

Seufz,

Dinu

[&quot;Martin v. Löwis&quot;]

Post by Dinu Gherman
Das ist vermutlich ein Teil des Problems. Ich hatte mich schon ge-
wundert, warum meine Terminal-Eingaben anscheinend in UTF-8 waren.
Tatsache ist, die Standard-Codierung findet man sehr wohl heraus,
die steht in ~/Library/Preferences/com.apple.Terminal.plist

Korrekt. Wie Du aber ausführst, kann man das ändern - und dann kann
man fast ebensogut UTF-8 als Default annehmen, wie diese Datei zu
lesen: man kann falsch raten.

Post by Dinu Gherman
Kniffliger wird es, wenn man fuer ein bestimmtes, geoeffnetes Fen-
ster eine solche Einstellung aendert. Dann kann ein Programm wohl
wirklich nur per AppleScript an die Einstellungen kommen.

Nein, nicht mal das. Viele Einstellungen sind über Applescript
abfragbar (etwa die Farben), aber nicht die Kodierung des aktuellen
(oder irgendeines) Fensters.

Abgesehen davon kann man AppleScript nur von pythonw aus ausführen
(python.exe müsste also osascript beim interaktiven Start ausführen,
was auch ein Hack wäre).

Ich wünschte, es gäbe einen ioctl auf /dev/tty, der mir das aktuelle
Encoding liefert. Ok wäre es auch, wenn Terminal.app für die Shell
eine Umgebungsvariable setzt (obwohl die dann ja auch keine Änderungen
mitbekommt - vielleicht kann man zusätzlich verbieten, dass die
Kodierung im laufenden Fenster geändert wird).

Post by Dinu Gherman
Ja, man koennte auch die Standardeinstellungen im Hintergrund temporaer
andern und ein neues Fenster aufmachen... Vielleicht geht ja wenigstens
so etwas mit AppleScript. Wer sich das nur ausgedacht hat, eine Art Pro-
grammiersprache fuer Nicht-Programmierer...

Manche sagen, es ist die einzige "read-only"-Programmiersprache (mit
Perl als dem Standardbeispiel für eine write-only-Sprache).

Ciao,
Martin