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