Umlautproblem in Python 2.3
Liebe Mitleser/innen, ein bißchen sehr spät, ich weiß -- aber ich habe gestern erst begriffen, welche Auswirkungen eine "kleine" Änderung hat, die mit Python 2.3 wirksam wird: Künftig erzeugt jedes Python-Skript eine Warnung, das irgendwo (z.B. Latin-1-)Umlaute enthält (und sei es nur in einem Kommentar), wenn nicht in der ersten oder zweiten Zeile der Datei der String "coding: Latin-1" (oder der Name eines anderen gültigen Kodes) erscheint. Obwohl ich schon seit längerer Zeit die CVS-Version von Python 2.3 häufig benutze, hat mich dieses Problem noch nicht gebissen, weil ich selten deutschsprachige Kommentare verwende. Ein Kollege macht jedoch sehr häufig davon Gebrauch und wird mit 2.3 alle seine Skripte ändern müssen. Ich weiß auch noch nicht, wie ich in der nächsten Woche den Teilnehmern meines Python-Kurses erklären soll, warum sie entweder auf Umlaute verzichten oder den ominösen String "# -*- coding: Latin-1 -*-" in jedes Programm tippen sollen. Kann mir von den Experten hier jemand erklären, warum überhaupt der gesamte Quelltext _vor_ der Syntaxanalyse umcodiert werden soll? (Sonst wären ja Kommentare syntaktisch zu erkennen und könnten ignoriert werden.) Die Python-Quellen selbst durften ja schon bisher außerhalb von Strings und Kommentaren nur ASCII pur enthalten; wenn das weiterhin so bleibt, würde es doch reichen, die Unicode-String-Konstanten aus einer source-spezifischen Kodierung in Unicode zu konvertieren. Daß in irgendeiner Quellkodierung auch alternative Zeilenwechsel oder Quotes enthalten sein könnten, heißt doch nicht, daß man diese auch benutzen muß?! Sorry, auch nochmaliges Lesen von PEP 263 hat mir keine echte Erleuchtung gebracht, und die Diskussion in c.l.py, die ich bei Google versucht habe nachzuvollziehen, gibt auch nicht viel her. (Die "ASCII-Muttersprachler" tun sich überhaupt schwer damit, das Problem zu erkennen.) Dies soll keine rhetorische (sprich trollige) Frage sein; ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals. Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Detlef Lannert wrote:
Kann mir von den Experten hier jemand erklären, warum überhaupt der gesamte Quelltext _vor_ der Syntaxanalyse umcodiert werden soll? (Sonst wären ja Kommentare syntaktisch zu erkennen und könnten ignoriert werden.) Die Python-Quellen selbst durften ja schon bisher außerhalb von Strings und Kommentaren nur ASCII pur enthalten;
Tatsaechlich darf eine Python-Quelle nach Spezifikation bis und mit 2.2 ausschliesslich ASCII enthalten, egal ob innerhalb oder ausserhalb von String-Literals und Kommentaren. Der Parser war bisher so zwar freundlich (oder nachlaessig), Abweichendes trotzdem zu schlucken, dieses Verhalten ist aber als Bug zu klassifizieren, welcher mit 2.3 nun behoben wird. Es hat ja ohnehin nur fuer diejenigen (vorwiegend westlichen) Sprachen "funktioniert", welche alle ihre Zeichen in 8 Bits unterbringen koennen. Nicht-ASCII Zeichensaetze koennen darum ohne Kennzeichnung nicht zugelassen werden, weil dann z.B. in gewissen Faellen nicht mehr erkennbar waere, wo die Zeilen aufhoeren. Bei Zeichensaetzen mit Multibyte-Codierung kann durchaus mal ein '\n' oder sonst etwas Unangenehmes als Teil eines 2-Byte Zeichens auch in der Mitte der Zeile vorkommen. Ohne Zeichensatz-Deklaration hat der Parser aber nicht die geringste Chance, den Unterschied zu erkennen. Die einzige Alternative stellen Unicode-Quellen in UTF-16 mit BOM dar, weil damit schon grundsaetzlich keine Mehrdeutigkeit mehr moeglich ist.
Dies soll keine rhetorische (sprich trollige) Frage sein; ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals.
Der Aerger ist in solchen Faellen wohl redlich verdient. ;) -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Georg Mischler <schorsch@schorsch.com> wrote:
Tatsaechlich darf eine Python-Quelle nach Spezifikation bis und mit 2.2 ausschliesslich ASCII enthalten, egal ob innerhalb oder ausserhalb von String-Literals und Kommentaren. Der Parser war bisher so zwar freundlich (oder nachlaessig), Abweichendes trotzdem zu schlucken, dieses Verhalten ist aber als Bug zu klassifizieren, welcher mit 2.3 nun behoben wird.
So einfach ist es leider nicht. Zitat aus dem Python Reference Manual, Release 2.3a0, noch vom Mai 2002: 8-bit characters may be used in string literals and comments but their interpretation is platform dependent; the proper way to insert 8-bit characters in string literals is by using octal or hexadecimal escape sequences. Die 8-Bit-Zeichen sind danach in Kommentaren zulässig, es ist nur keine Plattformunabhängigkeit gegeben. Und nur für String-Literale wird die Benutzung von Escape-Folgen empfohlen. Die an gleicher Stelle zu findende "Future compatibility note" sagt noch einmal (etwas verklausuliert), daß man sich auf eine Interpretation mit Latin-1 (in Strings) nicht verlassen solle.
Es hat ja ohnehin nur fuer diejenigen (vorwiegend westlichen) Sprachen "funktioniert", welche alle ihre Zeichen in 8 Bits unterbringen koennen.
Naja, immerhin. Die Programmierer im fernen Osten haben wahrscheinlich ihre lokalen Schriftzeichen ohnehin nur in Unicode- Strings untergebracht (seit es letztere gibt).
Bei Zeichensaetzen mit Multibyte-Codierung kann durchaus mal ein '\n' oder sonst etwas Unangenehmes als Teil eines 2-Byte Zeichens auch in der Mitte der Zeile vorkommen. Ohne Zeichensatz-Deklaration hat der Parser aber nicht die geringste Chance, den Unterschied zu erkennen.
OK, jetzt verstehe ich das Problem. Aber dann würde es genügen, für Multibyte-Codierungen eine Code-Deklaration zu verlangen, die ja bisher nicht verwendbar waren. UTF-8 macht freilich keine Schwierigkeiten, weil kein ASCII-Zeichen als Folgebyte auftreten kann.
Dies soll keine rhetorische (sprich trollige) Frage sein; ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals.
Der Aerger ist in solchen Faellen wohl redlich verdient. ;)
Das sehe ich nun wirklich nicht. Muß er tatsächlich damit rechnen, daß sein Programm zwar noch richtig läuft, aber Quelltextstücke angezeigt werden? Das wird dann eher noch ein Thema für Bugtraq ... Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
On Fri, 14 Feb 2003 19:30:27 +0100, Detlef Lannert wrote:
Die 8-Bit-Zeichen sind danach in Kommentaren zulässig, es ist nur keine Plattformunabhängigkeit gegeben. Und nur für String-Literale wird die Benutzung von Escape-Folgen empfohlen.
Python 2.3 ist auch eine Plattform, und zwar eine andere als 2.2. ;) Ciao, Jürgen _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Juergen Hermann <jh@web.de> wrote:
On Fri, 14 Feb 2003 19:30:27 +0100, Detlef Lannert wrote:
Die 8-Bit-Zeichen sind danach in Kommentaren zulässig, es ist nur keine Plattformunabhängigkeit gegeben. Und nur für String-Literale wird die Benutzung von Escape-Folgen empfohlen.
Python 2.3 ist auch eine Plattform, und zwar eine andere als 2.2. ;)
Ganz witzig, aber nicht wirklich hilfreich. Ich benutze Python (und habe hier ziemlich viel Reklame dafür gemacht) auch deshalb, weil Versionsänderungen (zumal um +0.1) bisher nicht als Plattformwechsel zuschlugen. Etliche meiner Programme sind seit 1999 unverändert im Einsatz und laufen noch problemlos mit 2.2 -- ich dachte, das wäre normal ... Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Detlef Lannert wrote:
Naja, immerhin. Die Programmierer im fernen Osten haben wahrscheinlich ihre lokalen Schriftzeichen ohnehin nur in Unicode- Strings untergebracht (seit es letztere gibt).
Auch bei Unicode-Literals in einem nicht-Unicode Quelltext muss der Zeichensatz bekannt sein, damit der Interpreter sie richtig verarbeiten kann. Kuerzlich wurde doch hier ein Unicode-FAQ gepostet, welches das sehr anschaulich erklaert. Das meiste, was ich zum Thema weiss, habe ich auch von dort...
OK, jetzt verstehe ich das Problem. Aber dann würde es genügen, für Multibyte-Codierungen eine Code-Deklaration zu verlangen, die ja bisher nicht verwendbar waren.
Der Parser hat keine Moeglichkeit, von sich aus festzustellen, ob ein 8-Bit Wert zu einem Single- oder einem Multibyte-Zeichen gehoert. Er muss also entweder fuer allen 8-Bit Input eine Deklaration vorschreiben, oder diesen komplett verbieten, wenn Mehrdeutigkeiten zuverlaessig vermieden werden sollen. Je schneller alle auf UTF-16 umstellen, desto besser... ;) -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Georg Mischler <schorsch@schorsch.com> wrote:
Auch bei Unicode-Literals in einem nicht-Unicode Quelltext muss der Zeichensatz bekannt sein, damit der Interpreter sie richtig verarbeiten kann.
Wenn nicht durchgängig Escape-Sequenzen für Nicht-ASCII-Zeichen verwendet werden. Sonst tut's jeder der (zahlreichen) Zeichensätze, die Erweiterungen von ASCII sind (alle ISO-8859, KOI-8R, ...).
OK, jetzt verstehe ich das Problem. Aber dann würde es genügen, für Multibyte-Codierungen eine Code-Deklaration zu verlangen, die ja bisher nicht verwendbar waren.
Der Parser hat keine Moeglichkeit, von sich aus festzustellen, ob ein 8-Bit Wert zu einem Single- oder einem Multibyte-Zeichen gehoert. Er muss also entweder fuer allen 8-Bit Input eine Deklaration vorschreiben, oder diesen komplett verbieten, wenn Mehrdeutigkeiten zuverlaessig vermieden werden sollen.
Bei den Single-Byte-Codierungen braucht der Parser dies nicht, ebensowenig wie bei UTF-8 (die unzulässigen UTF-8-Sequenzen weist Pythons decode() ja erfreulicherweise zurück). Daher müßte der Parser nur bei einigen der Multibyte-Codierungen != UTF-8 eine Deklaration haben, um "\n", "'" und '"' zu erkennen.
Je schneller alle auf UTF-16 umstellen, desto besser... ;)
Träum' weiter ... ;-)) Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Detlef Lannert wrote:
Liebe Mitleser/innen,
ein bißchen sehr spät, ich weiß -- aber ich habe gestern erst begriffen, welche Auswirkungen eine "kleine" Änderung hat, die mit Python 2.3 wirksam wird: Künftig erzeugt jedes Python-Skript eine Warnung, das irgendwo (z.B. Latin-1-)Umlaute enthält (und sei es nur in einem Kommentar), wenn nicht in der ersten oder zweiten Zeile der Datei der String "coding: Latin-1" (oder der Name eines anderen gültigen Kodes) erscheint.
Die Warnung läßt sich leicht abstellen, falls das ein Problem darstellen sollte. Sie ist hauptsächlich dazu gedacht, auf das Problem aufmerksam zu machen.
Obwohl ich schon seit längerer Zeit die CVS-Version von Python 2.3 häufig benutze, hat mich dieses Problem noch nicht gebissen, weil ich selten deutschsprachige Kommentare verwende.
Ein Kollege macht jedoch sehr häufig davon Gebrauch und wird mit 2.3 alle seine Skripte ändern müssen.
Naja, eine einzige Zeile per Shell-Skript voranzustellen kann doch nicht so schmerzhaft sein, oder ?
Ich weiß auch noch nicht, wie ich in der nächsten Woche den Teilnehmern meines Python-Kurses erklären soll, warum sie entweder auf Umlaute verzichten oder den ominösen String "# -*- coding: Latin-1 -*-" in jedes Programm tippen sollen.
Man kann auch ruhig eine weniger omiöse Variante verwenden (die dann allerdings nicht von Emacs erkannt wird), z.B. # Dieses Programm verwendet als Encoding: Latin-1 Die in Python verwendete RE ist sehr gnädig :-)
Kann mir von den Experten hier jemand erklären, warum überhaupt der gesamte Quelltext _vor_ der Syntaxanalyse umcodiert werden soll? (Sonst wären ja Kommentare syntaktisch zu erkennen und könnten ignoriert werden.) Die Python-Quellen selbst durften ja schon bisher außerhalb von Strings und Kommentaren nur ASCII pur enthalten; wenn das weiterhin so bleibt, würde es doch reichen, die Unicode-String-Konstanten aus einer source-spezifischen Kodierung in Unicode zu konvertieren. Daß in irgendeiner Quellkodierung auch alternative Zeilenwechsel oder Quotes enthalten sein könnten, heißt doch nicht, daß man diese auch benutzen muß?!
Der gesamte Quelltext wandert durch den Codec, daher sind auch Kommentare und sonstige Teile des Programms betroffen.
Sorry, auch nochmaliges Lesen von PEP 263 hat mir keine echte Erleuchtung gebracht, und die Diskussion in c.l.py, die ich bei Google versucht habe nachzuvollziehen, gibt auch nicht viel her. (Die "ASCII-Muttersprachler" tun sich überhaupt schwer damit, das Problem zu erkennen.)
Die Autoren des PEPs stammen allerings aus Düsseldorf und Berlin. Die Problematik ist also sehr wohl bekannt gewesen und auch der Grund weshalb mit die falsche Auslegung der Language Spec endlich geklärt werden sollte. Das PEP zeigt einen Weg heraus aus der Misere.
Dies soll keine rhetorische (sprich trollige) Frage sein; ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals.
Für solche Fälle kann man die Warnung abstellen (über das warning Modul). In Python 2.4 ist dann ein SyntaxError geplant, so daß der obige Fall nicht mehr eintreten kann ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 17 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 43 days left EuroPython 2003, Charleroi, Belgium: 127 days left _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
M.-A. Lemburg <mal@lemburg.com> wrote:
Künftig erzeugt jedes Python-Skript eine Warnung, das irgendwo (z.B. Latin-1-)Umlaute enthält (und sei es nur in einem Kommentar), wenn nicht in der ersten oder zweiten Zeile der Datei der String "coding: Latin-1" (oder der Name eines anderen gültigen Kodes) erscheint.
Die Warnung läßt sich leicht abstellen, falls das ein Problem darstellen sollte. Sie ist hauptsächlich dazu gedacht, auf das Problem aufmerksam zu machen.
Es wäre gut, wenn sie sich für eine Installation global abstellen ließe. Die Probleme, vor denen sie warnen soll, entstehen ja wohl vor allem beim Portieren von Programmen in andere Code-Umgebungen. Genauso nützlich wäre es, wenn man für eine Python-Installation sagen könnte, daß z.B. ein Encoding von UTF-8 zu unterstellen ist, wenn man mal darauf umgestellt hat. Ich finde den Gedanken etwas "abstoßend", in jedes Python-Skript auf Dauer eine Extrazeile aufzunehmen -- bzw. Neueinsteigern das ans Herz legen zu müssen.
Ein Kollege macht jedoch sehr häufig davon Gebrauch und wird mit 2.3 alle seine Skripte ändern müssen.
Naja, eine einzige Zeile per Shell-Skript voranzustellen kann doch nicht so schmerzhaft sein, oder ?
Bei Shell-Skripten nicht, denn davon gibt es nicht so viele <wink> -- aber bei Python-Skripten schon ... Erstens muß er alle finden, die auf irgendeinem Rechner ihren Dienst tun ;-). Zweitens denke an Versionsverwaltung und Release- Mechanismen; sonst hatte man immer eine Version lang Zeit, ein inkompatibles Feature "mutwillig" (from __future__) auszuprobieren.
Ich weiß auch noch nicht, wie ich in der nächsten Woche den Teilnehmern meines Python-Kurses erklären soll, warum sie entweder auf Umlaute verzichten oder den ominösen String "# -*- coding: Latin-1 -*-" in jedes Programm tippen sollen.
Man kann auch ruhig eine weniger omiöse Variante verwenden (die dann allerdings nicht von Emacs erkannt wird), z.B.
# Dieses Programm verwendet als Encoding: Latin-1
Tippen müssen sie das denn auch. Und dank Pythons Portabilität benutzen die Leute unterschiedliche Betriebssysteme (yuck!) und Editoren. Eine Methode, die Einfügung durch eine Editorkonfiguration zu automatisieren, kann ich deshalb nicht anbieten.
Der gesamte Quelltext wandert durch den Codec, daher sind auch Kommentare und sonstige Teile des Programms betroffen.
Das ist sicher die einfache Lösung, aber ich habe immer noch leise Zweifel, ob das so sein muß.
Die Autoren des PEPs stammen allerings aus Düsseldorf und Berlin.
... und verwenden wahrscheinlich genausowenig Umlaute in ihren Kommentaren wie ich??
ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals.
Für solche Fälle kann man die Warnung abstellen (über das warning Modul).
Dann macht das bitte (z.B. in den Release Notes) ganz deutlich. Ich sehe sonst wirklich das Risiko, zweifelhafte Popularität über Bugtraq zu gewinnen. (Ich denke da an Web-Logfiles, die von Leuten gelesen werden, die keinen Zugang zu den Skripten haben; an Warnungen, die in die Webseiten gehen; etc. etc.) Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Detlef Lannert wrote:
M.-A. Lemburg <mal@lemburg.com> wrote:
Künftig erzeugt jedes Python-Skript eine Warnung, das irgendwo (z.B. Latin-1-)Umlaute enthält (und sei es nur in einem Kommentar), wenn nicht in der ersten oder zweiten Zeile der Datei der String "coding: Latin-1" (oder der Name eines anderen gültigen Kodes) erscheint.
Die Warnung läßt sich leicht abstellen, falls das ein Problem darstellen sollte. Sie ist hauptsächlich dazu gedacht, auf das Problem aufmerksam zu machen.
Es wäre gut, wenn sie sich für eine Installation global abstellen ließe. Die Probleme, vor denen sie warnen soll, entstehen ja wohl vor allem beim Portieren von Programmen in andere Code-Umgebungen.
Das geht, wenn man das Abstellen in sitecutomize.py vornimmt.
Genauso nützlich wäre es, wenn man für eine Python-Installation sagen könnte, daß z.B. ein Encoding von UTF-8 zu unterstellen ist, wenn man mal darauf umgestellt hat. Ich finde den Gedanken etwas "abstoßend", in jedes Python-Skript auf Dauer eine Extrazeile aufzunehmen -- bzw. Neueinsteigern das ans Herz legen zu müssen.
Das wird auch kommen; es soll ebenso wie beim defaultencoding eine Möglichkeit geben, in sitecutomize.py den Defaultwert für das Source-Code-Encoding zu ändern.
Ein Kollege macht jedoch sehr häufig davon Gebrauch und wird mit 2.3 alle seine Skripte ändern müssen.
Naja, eine einzige Zeile per Shell-Skript voranzustellen kann doch nicht so schmerzhaft sein, oder ?
Bei Shell-Skripten nicht, denn davon gibt es nicht so viele <wink> -- aber bei Python-Skripten schon ...
Erstens muß er alle finden, die auf irgendeinem Rechner ihren Dienst tun ;-). Zweitens denke an Versionsverwaltung und Release- Mechanismen; sonst hatte man immer eine Version lang Zeit, ein inkompatibles Feature "mutwillig" (from __future__) auszuprobieren.
Die Warnung kann man auch "mutwillig" abstellen. Ist also alles nicht so schlimm :-)
Ich weiß auch noch nicht, wie ich in der nächsten Woche den Teilnehmern meines Python-Kurses erklären soll, warum sie entweder auf Umlaute verzichten oder den ominösen String "# -*- coding: Latin-1 -*-" in jedes Programm tippen sollen.
Man kann auch ruhig eine weniger omiöse Variante verwenden (die dann allerdings nicht von Emacs erkannt wird), z.B.
# Dieses Programm verwendet als Encoding: Latin-1
Tippen müssen sie das denn auch. Und dank Pythons Portabilität benutzen die Leute unterschiedliche Betriebssysteme (yuck!) und Editoren. Eine Methode, die Einfügung durch eine Editorkonfiguration zu automatisieren, kann ich deshalb nicht anbieten.
In diesem Fall würde ich vorschlagen, allen Quellcode in UTF-8 mit BOM abzuspeichern. Damit erspart man sich dann auch den Kommentar.
Der gesamte Quelltext wandert durch den Codec, daher sind auch Kommentare und sonstige Teile des Programms betroffen.
Das ist sicher die einfache Lösung, aber ich habe immer noch leise Zweifel, ob das so sein muß.
Es ist die eleganteste Lösung und auch von der Language Spec so abgesegnet.
Die Autoren des PEPs stammen allerings aus Düsseldorf und Berlin.
... und verwenden wahrscheinlich genausowenig Umlaute in ihren Kommentaren wie ich??
Naja, deutsche Kommentare sind eher die Seltenheit bei mir, aber sie kommen hin und wieder vor. Vor allem dann, wenn der Auftraggeber dies gerne so hätte.
ich sehe im 2.3-Verhalten von Python aber sogar ein potentielles Sicherheitsproblem, weil in den (lästigen!) Warnungsmeldungen die erste Zeile auftaucht, die Umlaute o.ä. hat. Wenn sie Paßwörter oder abfällige Bemerkungen enthält -- was bisher in einigen Einsatzfällen unkritisch war --, hat der Autor Ärger am Hals.
Für solche Fälle kann man die Warnung abstellen (über das warning Modul).
Dann macht das bitte (z.B. in den Release Notes) ganz deutlich. Ich sehe sonst wirklich das Risiko, zweifelhafte Popularität über Bugtraq zu gewinnen. (Ich denke da an Web-Logfiles, die von Leuten gelesen werden, die keinen Zugang zu den Skripten haben; an Warnungen, die in die Webseiten gehen; etc. etc.)
Das ist ein gutes Argument. Ich denke, daß es ausreicht die betreffende Zeile per Zeilennummer anzuzeigen. Werde ich ändern. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 17 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 43 days left EuroPython 2003, Charleroi, Belgium: 127 days left _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Detlef Lannert <lannert@uni-duesseldorf.de> writes:
Genauso nützlich wäre es, wenn man für eine Python-Installation sagen könnte, daß z.B. ein Encoding von UTF-8 zu unterstellen ist, wenn man mal darauf umgestellt hat. Ich finde den Gedanken etwas "abstoßend", in jedes Python-Skript auf Dauer eine Extrazeile aufzunehmen -- bzw. Neueinsteigern das ans Herz legen zu müssen.
Meine Empfehlung: Verwende einen Editor, der "stillschweigend" Texte in UTF-8 abspeichert und ein UTF-8-BOM voranstellt (etwa Microsoft notepad). Dieses ist ebenfalls eine Deklaration der Kodierung, aber man sieht sie nicht - ich nehme an, dass der Anblick der Deklaration das ist, was Dich abstößt.
Erstens muß er alle finden, die auf irgendeinem Rechner ihren Dienst tun ;-). Zweitens denke an Versionsverwaltung und Release- Mechanismen; sonst hatte man immer eine Version lang Zeit, ein inkompatibles Feature "mutwillig" (from __future__) auszuprobieren.
Hier ist es genauso. Es gibt eine Version Zeit, danach ist es ein Fehler (und nicht nur eine Warnung), wenn man nicht-ASCII-Bytes in einer Quelldatei verwendet, aber keine Kodierung deklariert hat. Falls die Analogie nicht offensichtlich ist: Bei Einführung der Generatoren wurde "yield" ein Schlüsselwort. Dabei wurde *sofort* eine Warnung ausgegeben, wenn "yield" als Bezeichner verwendet wurde; wollte man es als Schlüsselwort verwenden, brauchte man den future import. Also: In der Transitionsphase gibt es Warnungen, danach Fehlermeldungen.
Das ist sicher die einfache Lösung, aber ich habe immer noch leise Zweifel, ob das so sein muß.
Wenn man erst parst und dann die Kodierung anwendet, erkennt man beispielsweise das String-Ende nicht - es gibt Kodierungen (BIG-5), bei denen das Byte für Backslash (\) auch als zweites Byte auftreten kann. Wenn ein solches Zeichen unmittelbar vor dem abschließenden " auftritt, verschluckt sich der Parser.
Die Autoren des PEPs stammen allerings aus Düsseldorf und Berlin.
... und verwenden wahrscheinlich genausowenig Umlaute in ihren Kommentaren wie ich??
Ganz im Gegenteil. Ich habe in vielen Quelldateien eine Zeile, in der # Martin v. Löwis steht. In diesen Dateien gibt es jetzt auch eine Deklaration der Kodierung. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Martin v. Löwis <martin@v.loewis.de> wrote:
Genauso nützlich wäre es, wenn man für eine Python-Installation sagen könnte, daß z.B. ein Encoding von UTF-8 zu unterstellen ist, wenn man mal darauf umgestellt hat. Ich finde den Gedanken etwas "abstoßend", in jedes Python-Skript auf Dauer eine Extrazeile aufzunehmen -- bzw. Neueinsteigern das ans Herz legen zu müssen.
Meine Empfehlung: Verwende einen Editor, der "stillschweigend" Texte in UTF-8 abspeichert und ein UTF-8-BOM voranstellt (etwa Microsoft notepad). Dieses ist ebenfalls eine Deklaration der Kodierung, aber man sieht sie nicht - ich nehme an, dass der Anblick der Deklaration das ist, was Dich abstößt.
Mittel- bis langfristig kann das eine Lösung für mich sein, aber derzeit unterstützt das mein Editor nicht, ebensowenig das Druckprogramm [a2ps] etc.; notepad wird für dieses Betriebssystem (wohl auch in Zukunft) nicht angeboten ;-) . Wie schon gesagt, kann ich bei Kursen mit heterogenem Teilnehmerkreis nicht eine allgemeingültige Editorempfehlung und -konfiguration vorgeben. Deswegen bin ich zunächst dazu übergegangen, den Teilnehmern zu empfehlen, gar keine Umlaute zu verwenden. Was nicht gerade auf Begeisterung stieß. Im übrigen taugt diese Empfehlung nicht für Unix-Skripts. Um einen Interpreter zu starten, muß das Skript mit #! beginnen; wenn dem eine BOM vorausgeht, wird das Hash-Bang nicht erkannt, sondern (als Default) die Shell gestartet. Und die meckert über die BOM. Sicherheitshalber noch mal ausprobiert unter Linux 2.4/SuSE 8.1: paco:~ $ file /tmp/test.utf /tmp/test.utf: UTF-8 Unicode text paco:~ $ /tmp/test.utf /tmp/test.utf: line 1: #!: command not found /tmp/test.utf: line 3: print: command not found paco:~ $
Wenn man erst parst und dann die Kodierung anwendet, erkennt man beispielsweise das String-Ende nicht - es gibt Kodierungen (BIG-5), bei denen das Byte für Backslash (\) auch als zweites Byte auftreten kann. Wenn ein solches Zeichen unmittelbar vor dem abschließenden " auftritt, verschluckt sich der Parser.
Das sind aber nur ganz wenige Kodierungen, die auch bisher ungeeignet waren, um Python-Source zu schreiben. Mit den ISO-8859-x und KOI* gibt es AFAIK dieses Problem gar nicht. Detlef _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
participants (5)
-
Detlef Lannert -
Georg Mischler -
Juergen Hermann -
M.-A. Lemburg -
martin＠v.loewis.de