RE: XML, Umlaute, Unicode, Projektorganisation, RPC, MPUC - Wer bietet mehr?
Liest sich ganz gut, aber: <!ENTITY ouml "ö"> Woher weiß man das man hier #246 eingeben muß? Der link auf Python-Unicode-Faq gibt 404 zurück.
Danke, ich habe beides korrigiert.
Was ist Büdong?
Lautmalerisches Kosewort für Python? _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
Liest sich ganz gut, aber: <!ENTITY ouml "ö"> Woher weiß man das man hier #246 eingeben muß? Der link auf Python-Unicode-Faq gibt 404 zurück.
Danke, ich habe beides korrigiert.
Hm. Gibts eigentlich mehrere ö's (ich stell mich jetzt mal ganz dumm)? Sieht nämlich ganz so aus: Win XP console: C:\>py22 Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
ord("ö") 148
IDLE, von 2.3: (Bemerkung: im IDLE Fenster sieht das ö wie ein ö aus, aber nicht mehr, nachdem ich das hier in XEmacs reinkopiert habe) PythonWin 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond@skippinet.com.au) - see 'Help/About PythonWin' for further copyright information.
ord("ö") 246
IDLE, von 2.2.2: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help
ord("ö") UnicodeError: ASCII encoding error: ordinal not in range(128)
Was ist Büdong?
Lautmalerisches Kosewort für Python? Na dann, ich dachte schon ich hätte da was verpasst.
Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hm. Gibts eigentlich mehrere ö's (ich stell mich jetzt mal ganz dumm)?
http://p-nand-q.com/python/unicode_faq.html, abschnitt "Unicode in Python" print """ Bevor wir einsteigen, gleich drei Warnungen für Windowsbenutzer. - Pythonwin ist eine prima Python-IDE, die aber (zumindest in der aktuellen Version - build 150) Probleme mit Unicode-Zeichen hat, die direkt eingegeben werden (im Quelltext, oder im Interaktiven Fenster). Genauer, wenn man in der interaktiven Shell ein "ü" eingeben will, ist beim ersten mal " Tippen dieses Zeichen nicht sichtbar, aber gültig. Wenn man nochmal " tippt, damit man das Zeichen sieht, ist das ein Syntaxfehler. - Das cygwin-Python hat auch so seine Eingabeprobleme. Genauer, wenn man ein ü tippt, passiert gar nichts. - Leider hat auch die Win32-Console so seine Probleme mit Sonderzeichen. Genauer, die Console arbeitet auch auf einem deutschen Windows NT mit der Codepage 437, in der wie oben beschrieben die deutschen Umlaute anders dargestellt werden als etwa in Notepad (das mit der Windows-ANSI-Codepage arbeitet). (Das ist übrigens der Grund für folgendes: Wenn man im DevStudio ein C++ Programm schreibt, das Umlaute per printf ausgibt, sind die Umlaute in der Konsole nicht lesbar - weil sie in einer anderen Codepage dargestellt werden). Näheres zu der haarigen Unicode-Unterstützung von Win32 gibt es in einem eigenen Kapitel, weiter unten. Um die folgenden Beispiele unter Windows durchführen, gibt es drei Möglichkeiten: - Erstellen eines Beispieltextes in Notepad, ausführen mit Python. - Trotz aller Nachteile die Win32 Console-Version von Python einsetzen. - Linux installieren """ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
Hm. Gibts eigentlich mehrere ö's (ich stell mich jetzt mal ganz dumm)?
http://p-nand-q.com/python/unicode_faq.html,
abschnitt "Unicode in Python" [...]
Ja, ich habe das inzwischen jetzt auch gelesen. Das macht aber das ord("ö") Rezept ziemlich zweifelhaft. Vielleicht sollte man dann lieber charmap.exe empfehlen?
eigenen Kapitel, weiter unten. Um die folgenden Beispiele unter Windows durchführen, gibt es drei Möglichkeiten:
- Erstellen eines Beispieltextes in Notepad, ausführen mit Python. Hm.
- Trotz aller Nachteile die Win32 Console-Version von Python einsetzen.
Die zeigt aber auch ord("ö") falsch an.
- Linux installieren Super Idee.
Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Thomas Heller wrote:
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
- Linux installieren Super Idee.
Um weniger Charset-Probleme zu haben? ROTFLMAO. -- Gerhard _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerhard Häring <gh@ghaering.de> writes:
Thomas Heller wrote:
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
- Linux installieren Super Idee.
Um weniger Charset-Probleme zu haben? ROTFLMAO.
Um jetzt mal von Gersons Tutorial etwas wegzugehen: Wie schreibt man denn nun tatsächlich Umlaute in Python-Quellcode damit es funktioniert? Nach dem was ich bis jetzt verstanden habe: ----- # -*- encoding: latin-1 -*- dumb = u"blöd" ----- Das sollte dann in 2.2 und in 2.3 richtig sein, und auch unabhängig davon was als default encoding eingestellt ist, oder? Für koreanische Zeichen bleibt dann wahrscheinlich nur die als Escape einzugeben (obwohl *ich* das Problem garnicht habe). Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Am Wed, Jul 23, 2003 at 06:26:41PM +0200, Thomas Heller schrieb:
Gerhard Häring <gh@ghaering.de> writes:
Thomas Heller wrote:
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
- Linux installieren Super Idee.
Um weniger Charset-Probleme zu haben? ROTFLMAO.
Um jetzt mal von Gersons Tutorial etwas wegzugehen: Wie schreibt man denn nun tatsächlich Umlaute in Python-Quellcode damit es funktioniert?
Nach dem was ich bis jetzt verstanden habe:
----- # -*- encoding: latin-1 -*-
dumb = u"blöd" -----
Das sollte dann in 2.2 und in 2.3 richtig sein, und auch unabhängig davon was als default encoding eingestellt ist, oder? Für koreanische Zeichen bleibt dann wahrscheinlich nur die als Escape einzugeben (obwohl *ich* das Problem garnicht habe).
Komisch ich verwende Python 2.1 (von Debian Woody) und bei mir geht das so:
string = "ü" print string ü "ä" '\xe4'
Ich weis allerdings net warum das bei mir geht... Damit hab ich mich aber eigentlich auch net weiter befasst, da es ja bei mir geht (wenn was geht sollte ja alles i.o. sein oder?) mfg Betz Stefan -- Profitip No. 413: Zeit sparen durch Rebooten im Hintergrund. Man will ja nicht jedesmal die Arbeit unterbrechen... stefan@athlon.hornynet:~$ reboot & _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Stefan J. Betz wrote:
Komisch ich verwende Python 2.1 (von Debian Woody) und bei mir geht das so:
string = "ü" print string
ü
"ä"
'\xe4'
Ich weis allerdings net warum das bei mir geht... [...]
Warum sollte es nicht gehen? Es ging ja um Unicode-Strings.
print u"ü"
Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) -- Gerhard _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Thomas Heller <theller@python.net> writes:
# -*- encoding: latin-1 -*-
dumb = u"blöd"
In etwa so (besser: "coding", nicht "encoding" - dann versteht das auch der Emacs).
Das sollte dann in 2.2 und in 2.3 richtig sein
Leider nur 2.3. IDLE kann das (1.0) und ein paar andere Editoren; Python 2.3 erzeugt den _richtigen_ Unicode-String, und print gibt ihn auf alle möglichen Terminalfenster (einschließlich cmd.exe) richtig aus.
und auch unabhängig davon was als default encoding eingestellt ist, oder? Für koreanische Zeichen bleibt dann wahrscheinlich nur die als Escape einzugeben (obwohl *ich* das Problem garnicht habe).
Für koreanische Zeichen im Quelltext empfehle ich, UTF-8 als Kodierung zu verwenden. Manche Leute empfehlen, das grundsätzlich zu tun - falls alle nicht-ASCII-Strings im Quelltext Unicode-Strings sind, spricht auch nichts dagegen. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:
Thomas Heller <theller@python.net> writes:
# -*- encoding: latin-1 -*-
dumb = u"blöd"
In etwa so (besser: "coding", nicht "encoding" - dann versteht das auch der Emacs).
Ok. Leider XEmacs (unter Windows) nicht, da es den nicht als Mule gibt.
Das sollte dann in 2.2 und in 2.3 richtig sein
Leider nur 2.3. IDLE kann das (1.0) und ein paar andere Editoren; Python 2.3 erzeugt den _richtigen_ Unicode-String, und print gibt ihn auf alle möglichen Terminalfenster (einschließlich cmd.exe) richtig aus.
Ich hab das anscheinend doch noch nicht verstanden. 1. Woher weiß Python welche Kodierung die Console benutzt? 2. Ich habe PEP 263 so verstanden, daß es nur um Unicode Literale im Quelltext geht, die dann wohl bei der Kompilierung in unicode Objekte umgewandelt werden. Daher ist dann auch das Encoding aus dem comment später nicht mehr zugänglich (weil es auch garnicht mehr gebraucht wird). 3. Ich habe in dem Beispiel oben latin-1 hingeschrieben, weil ich PEP 263 so verstanden habe daß das in Python 2.1 und 2.2 der Default ist, und ich dachte daß das Ganze dann portabel zwischen 2.2 und 2.3 ist. Scheint aber nicht so zu sein.
Für koreanische Zeichen im Quelltext empfehle ich, UTF-8 als Kodierung zu verwenden. Manche Leute empfehlen, das grundsätzlich zu tun - falls alle nicht-ASCII-Strings im Quelltext Unicode-Strings sind, spricht auch nichts dagegen.
Es geht mir um eine Python Quelldatei die als Konfigurationsscript dient. Möglicherweise tippen dann doch koreanische Benutzer (keine Programmierer) darin herum, daher lieber explizite Zeichen als Escapesequenzen. Mit utf-8 Kodierung und notfalls Notepad als Editor sollte das dann also (in 2.3) gehen? Danke, Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Thomas Heller <theller@python.net> writes:
Ich hab das anscheinend doch noch nicht verstanden.
1. Woher weiß Python welche Kodierung die Console benutzt?
GetConsoleCP/GetConsoleOutputCP unter Windows, nl_langinfo(CODESET) unter Unix.
2. Ich habe PEP 263 so verstanden, daß es nur um Unicode Literale im Quelltext geht, die dann wohl bei der Kompilierung in unicode Objekte umgewandelt werden. Daher ist dann auch das Encoding aus dem comment später nicht mehr zugänglich (weil es auch garnicht mehr gebraucht wird).
Korrekt.
3. Ich habe in dem Beispiel oben latin-1 hingeschrieben, weil ich PEP 263 so verstanden habe daß das in Python 2.1 und 2.2 der Default ist, und ich dachte daß das Ganze dann portabel zwischen 2.2 und 2.3 ist.
Ach so. Wenn Du tatsächlich lediglich Latin-1-Zeichen brauchst, dann ist es wirklich portabel (über Versionen hinweg), Latin-1 als Quellkodierung zu verwenden.
Es geht mir um eine Python Quelldatei die als Konfigurationsscript dient. Möglicherweise tippen dann doch koreanische Benutzer (keine Programmierer) darin herum, daher lieber explizite Zeichen als Escapesequenzen. Mit utf-8 Kodierung und notfalls Notepad als Editor sollte das dann also (in 2.3) gehen?
Genau. Wenn die Datei initial ein BOM hat, versteht entweder der Editor, was gemeint ist, oder er zeigt gleich am Anfang "funny characters", und die Nutzer nehmen vielleicht davon Abstand, in der Datei herumzutippen. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:
Thomas Heller <theller@python.net> writes:
Ich hab das anscheinend doch noch nicht verstanden.
1. Woher weiß Python welche Kodierung die Console benutzt?
GetConsoleCP/GetConsoleOutputCP unter Windows, nl_langinfo(CODESET) unter Unix.
Scheint als müßte ich öfter mal wieder im Python Quellcode schmökern. Habe gerade deinen Patch 612627 angesehen, jetzt wird mir das alles klarer. Das einzige was ich noch nicht verstanden habe: warum ist das .encoding Attribut von Files eigentlich read-only? Für die stdin/stdout ist das klar, aber was ist mit normalen Dateien?
3. Ich habe in dem Beispiel oben latin-1 hingeschrieben, weil ich PEP 263 so verstanden habe daß das in Python 2.1 und 2.2 der Default ist, und ich dachte daß das Ganze dann portabel zwischen 2.2 und 2.3 ist.
Ach so. Wenn Du tatsächlich lediglich Latin-1-Zeichen brauchst, dann ist es wirklich portabel (über Versionen hinweg), Latin-1 als Quellkodierung zu verwenden.
Ah, sehr gut. Danke, und übrigens noch meinen Glückwunsch zum Activator Award. Den hast Du wirklich verdient, meiner unmaßgeblichen Meinung nach! Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Martin v. Löwis <martin@v.loewis.de> wrote:
3. Ich habe in dem Beispiel oben latin-1 hingeschrieben, weil ich PEP 263 so verstanden habe daß das in Python 2.1 und 2.2 der Default ist, und ich dachte daß das Ganze dann portabel zwischen 2.2 und 2.3 ist.
Ach so. Wenn Du tatsächlich lediglich Latin-1-Zeichen brauchst, dann ist es wirklich portabel (über Versionen hinweg), Latin-1 als Quellkodierung zu verwenden.
Wenn ich mich recht entsinne, war für Python 2.3 versprochen worden, daß die PendingDeprecationWarning (z.B. bei Umlauten in Kommentaren) global abgestellt werden kann oder auch für ein System die Source Encoding z.B. auf Latin-1 voreingestellt werden kann (mit den bekannten Risiken, wenn man die Sources dann z.B. nach Südostasien verschickt). Wie geht das denn nun?
Es geht mir um eine Python Quelldatei die als Konfigurationsscript dient. Möglicherweise tippen dann doch koreanische Benutzer (keine Programmierer) darin herum, daher lieber explizite Zeichen als Escapesequenzen. Mit utf-8 Kodierung und notfalls Notepad als Editor sollte das dann also (in 2.3) gehen?
Genau. Wenn die Datei initial ein BOM hat, versteht entweder der Editor, was gemeint ist, oder er zeigt gleich am Anfang "funny characters", und die Nutzer nehmen vielleicht davon Abstand, in der Datei herumzutippen.
Dafür ist die Datei dann unter Linux nicht mehr als ausführbares Programm zu gebrauchen (das #! wird nicht erkannt). Unter Windows mag das gehen, für Linux ist auf absehbare Zeit dringend davon abzuraten. Detlef _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Detlef Lannert wrote:
[Quelldateien mit BOM] Dafür ist die Datei dann unter Linux nicht mehr als ausführbares Programm zu gebrauchen (das #! wird nicht erkannt). Unter Windows mag das gehen, für Linux ist auf absehbare Zeit dringend davon abzuraten.
Ja, aber es gibt einen Würgaround: ein Wrapperskript dass das Hauptmodul importiert und main() aufruft. -- Gerhard _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Detlef Lannert <lannert@uni-duesseldorf.de> writes:
Wenn ich mich recht entsinne, war für Python 2.3 versprochen worden, daß die PendingDeprecationWarning (z.B. bei Umlauten in Kommentaren) global abgestellt werden kann
Dieser Satz nimmt zwei separate Versprechen an: 1. PendingDeprecationWarning kann man global abschalten. Das ist so, und sie sind sogar by default abgeschaltet (-Wall) 2. Umlaute in Kommentaren führen zu PendingDeprecationWarning. Das ist nicht so, und war auch nicht versprochen worden; statt dessen führen sie zu DeprecationWarning. Mit dem warnings-Modul kann man natürlich diese Warnung wie auch jede andere abschalten.
Dafür ist die Datei dann unter Linux nicht mehr als ausführbares Programm zu gebrauchen (das #! wird nicht erkannt). Unter Windows mag das gehen, für Linux ist auf absehbare Zeit dringend davon abzuraten.
Ich habe persönlich nicht den Drang, davon abzuraten :-) Stimmt, man kann das für Skripte gegenwärtig nicht verwenden, aber a) heute ist nicht aller Tage, und b) nicht alle Quelltextfiles sind Skripte Ciao, Martin --- binfmt_script.c.orig Mon Feb 25 06:28:36 2002 +++ binfmt_script.c Mon Feb 25 07:48:19 2002 @@ -1,7 +1,7 @@ /* * linux/fs/binfmt_script.c * - * Copyright (C) 1996 Martin von Löwis + * Copyright (C) 1996, 2002 Martin von Löwis * original #!-checking implemented by tytso. */ @@ -23,7 +23,16 @@ char interp[BINPRM_BUF_SIZE]; int retval; - if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') || (bprm->sh_bang)) + /* It is a recursive invocation. */ + if (bprm->sh_bang) + return -ENOEXEC; + + /* It starts neither with #!, nor with #! preceded by + the UTF-8 signature. */ + if (!(((bprm->buf[0] == '#') && (bprm->buf[1] == '!')) + || ((bprm->buf[0] == '\xef') && (bprm->buf[1] == '\xbb') + && (bprm->buf[2] == '\xbf') && (bprm->buf[3] == '#') + && (bprm->buf[4] == '!')))) return -ENOEXEC; /* * This section does the #! interpretation. @@ -46,7 +55,8 @@ else break; } - for (cp = bprm->buf+2; (*cp == ' ') || (*cp == '\t'); cp++); + cp = (bprm->buf[0]=='\xef') ? bprm->buf+5 : bprm->buf+2; + while ((*cp == ' ') || (*cp == '\t')) cp++; if (*cp == '\0') return -ENOEXEC; /* No interpreter name found */ i_name = cp; _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Wie schreibt man denn nun tatsächlich Umlaute in Python-Quellcode damit es funktioniert?
Ich würde sagen, das hängt von der Zielgruppe ab. Wenn ich Umlaute verwende, dann ja für Text, den ich am Bildschirm irgendwie anzeigen will. Der Computer selber spricht ja kein Deutsch, *Menschen* oder zumindest gutgemachte Menschensimulationen (Denn SIE sind unter uns...) sprechen Deutsch. Zum Anzeigen brauche ich ein Medium: - Ein GUI, z.B. wxPython - Ausgabe am Prompt - HTML-Ausgabe - XML-Ausgabe usw. Für sowas wie wxPython brauche ich gar kein Encoding, sondern einfach ein "ü" in der Windows-Codepage. Es wird nix bringen, wenn ich die Datei in UTF16LE ablege: weil der C++ Kern ganz normale "unsaubere" Bytezeichenbatzen nimmt. (Es gibt wohl einen experimentellen Unicode-Build von wxPython). Eher schon erwarte ich eine Encodingexception, wenn ich wxPython damit quäle. An dieser Stelle der leicht entflammbare Einschub: Es ist ja wunderschön, daß wir uns um koreanische Zeichensätze kümmern, aber die Python-Unicode-Behandlung kommt mir schon ein bisserl korinthenkackerisch vor. Das kann man schon alleine daran erkennen, *wie oft* und *wie viele* Fragen dazu gestellt wurden und noch werden. Ich kann mich nicht erinnern, daß ich in grauer Vorzeit, als ich Assembler oder Pascal oder C oder C++ erlernte, Umlaute als ein PROBLEM DER INFORMATIK erkannt habe. Wieviele C/C++-Programme wurden rein für den deutschen Markt erstellt, mit "ü"s drin: und war diese Tatsache nicht das *aller*geringste Problem der Sw-Entwicklung? Wie groß ist der Markt für Programme mit "ü"s drin in Südostasien? Ganz besonders nervt es mich, wenn man z.B. ein großes Projekt hat, und per Murphy kommt an einer Codestelle, die nur an ungeraden Wochentagen in Monaten die durch eine Primzahl teilbar sind aufgerufen wird, und dann kommt eine dumme Encodingexception auf die keiner gefasst ist und das Programm beendet sich. Noch anders ausgedrückt. Wenn in einem Sourcecode, der von (z.B.) "Unfallverhütungsvorschriften für beschäftigtenbediente Banknotenautomaten" handelt, ein Thema, welches selbst in Deutschland nur einen Menschenkreis von Supermodellartig geringem Umfang interessiert, ein Byte \xFC drin vorkommt, DANN IST DAS EIN Ü. Klar? ICH SCHWÖRE. Auch halte ich es für übereilt, die Schlußfolgerung zu ziehen, sämtliche pyds dieser Erde kämen mit etwas anderem als 8-Bit-Byte-Buchstabensalaten zurecht. Ende des Einschubs. Wenn ich es am prompt ausgebe, unter NT, habe ich das Codepage-Problem. Aber, das ist ein allgemeines Problem; wie schon erwähnt zeitigt printf("ü") genau das gleiche ärgerliche Verhalten. In HTML habe ich mir mühsam angewöhnt, &?uml; und co zu verwenden; in XML siehe meine zur allseitigen Erheiterung ins Netz gestellten Ergüsse. _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
Wie schreibt man denn nun tatsächlich Umlaute in Python-Quellcode damit es funktioniert?
Ich würde sagen, das hängt von der Zielgruppe ab. Wenn ich Umlaute verwende, dann ja für Text, den ich am Bildschirm irgendwie anzeigen will. Der Computer selber spricht ja kein Deutsch, *Menschen* oder zumindest gutgemachte Menschensimulationen (Denn SIE sind unter uns...) sprechen Deutsch.
Zum Anzeigen brauche ich ein Medium:
- Ein GUI, z.B. wxPython - Ausgabe am Prompt - HTML-Ausgabe - XML-Ausgabe
usw.
Für sowas wie wxPython brauche ich gar kein Encoding, sondern einfach ein "ü" in der Windows-Codepage. Es wird nix bringen, wenn ich die Datei in UTF16LE ablege: weil der C++ Kern ganz normale "unsaubere" Bytezeichenbatzen nimmt. (Es gibt wohl einen experimentellen Unicode-Build von wxPython). Eher schon erwarte ich eine Encodingexception, wenn ich wxPython damit quäle.
Vielleicht verstehe ich das ja immer noch nicht richtig, aber mir geht es zunächst mal darum daß Python versteht daß ich ein 'ü' meine. Die Anzeige muß natürlich auch richtig gemacht werden.
An dieser Stelle der leicht entflammbare Einschub: Es ist ja wunderschön, daß wir uns um koreanische Zeichensätze kümmern, aber die Python-Unicode-Behandlung kommt mir schon ein bisserl korinthenkackerisch vor. Das kann man schon alleine daran erkennen, *wie oft* und *wie viele* Fragen dazu gestellt wurden und noch werden. Ich kann mich nicht erinnern, daß ich in grauer Vorzeit, als ich Assembler oder Pascal oder C oder C++ erlernte, Umlaute als ein PROBLEM DER INFORMATIK erkannt habe.
Ich weiß moch genau, wie in meiner grauen Vorzeit (das war als Computer noch große Schränke und sehr teuer waren) ich mich immer gewundert habe, gerade weil die so aufwendig waren, trotzdem nicht richtig Deutsch konnten. Das lag natürlich auch daran daß auf den Kettendruckern überhaupt keine Umlaute gedruckt werden konnten, kein ß aud der Kette war usw.
Wieviele C/C++-Programme wurden rein für den deutschen Markt erstellt, mit "ü"s drin: und war diese Tatsache nicht das *aller*geringste Problem der Sw-Entwicklung? Wie groß ist der Markt für Programme mit "ü"s drin in Südostasien? Es geht mir weniger um das ü als mehr um das µ z.B. Und wir haben hier in der Firma rein englischsprachliche Programme (allerdings für einen weltweiten Markt) entwickelt. Teilweise passierte es dann, daß statt irgendwelchen Zeichen nur Kreise auf dfem Bildschirm erscheinen, oder daß beispielsweise Dialoge überhaupt nicht 'aufgingen' wenn der Rechner in Korea oder Japan auf die dort üblichen Einstellungen gestellt wurde. Deshalb würde ich es gerne endlich richtig machen.
Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Python-Unicode-Behandlung kommt mir schon ein bisserl korinthenkackerisch vor. Das kann man schon alleine daran erkennen, *wie oft* und *wie viele*
Ich habe hier ja auch schon gefragt und genervt ;-) Ich bin (leider) auch Deiner Meinung. Sehr vieles an Python gefällt mir, aber diese dunkle Ecke nicht. Es ist wirklich ein Punkt, der mir den Spaß an Python ein Stück weit verringert hat. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (7)
-
Detlef Lannert -
Gerhard Häring -
Gerson.Kurz＠t-online.de -
Klaus Meyer -
martin＠v.loewis.de -
Stefan J. Betz -
Thomas Heller