[Python-de] Was sein sollte

Stefan Schwarzer sschwarzer at sschwarzer.net
Mit Dez 31 17:33:59 CET 2003


Hallo Gerson,

On Wed, 2003-12-31 07:46:46 +0100, Gerson Kurz wrote:
> Martin v. Loewis schrub:
> 
> > > 1) "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen und
> > Willst Du das wirklich? Aus dieser Warnung wird irgendwann mal ein
> > Syntaxfehler. Dann werden sich die Leute beschweren, nicht gewarnt
> > worden zu sein.
> 
> Bitte bitte sag daß das nicht wahr ist. Zeit für einen fork oder was?
> [...]
> Warum muß ein Encodingproblem ein Programm hart beenden?
> 
> Nochmal: für relativ viele Probleme ist es mir wurschtegal, ob ü ? ist.
> Nicht-wurschtegal ist mir hingegen, ob das Encoding dazu führt, daß Probleme
> in für den Hauptzweck des Programmes völlig unrelevanten Bereichen wie sagen
> wir einem Logfile auftreten.
> 
> Du willst ein Beispiel aus der Praxis?
> [...]

ich finde deine Begründung nicht ausreichend, um das standardmäßige
Verhalten von Python zu ändern. Ich denke eher, dass deine
Anforderungen eher die Ausnahme als die Regel sind, so dass man nicht
die reguläre Python-Distribution mit dem entsprechend geänderten
Verhalten "belasten" sollte.

Wenn ich in Python programmiere, will ich in einer mehrdeutigen
Situation lieber eine Laufzeit-Exception als ein stilles Ignorieren
eines möglichen Fehlers. Ich schätze das Motto "explicit is better
than implicit" und die Konsistenz in Python, auch und gerade, was die
Exceptions betrifft.

Ein anderes Beispiel: Wenn man int() einen String übergibt, der sich
nicht in eine Zahl wandeln lässt, z. B. "123x", wird ein ValueError
ausgelöst. Für einige Anwendungen wäre es völlig ausreichend, wenn
int() in diesem Fall einfach den Wert 0 zurückliefern würde, aber ich
finde gut, dass es nicht so ist. Wenn es einen undefinierten Zustand
gibt, will ich das - ggf. durch einen Traceback, das übliche
Python-Verhalten in solchen Fällen - wissen. Dass ich mein Programm
entsprechend gut testen muss, halte ich für selbstverständlich.

Du hast ein Beispiel genannt, in dem du es lieber hättest, das
Programm würde trotz unklarem Code ohne Exception weiterlaufen. Für
deine spezielle Anwendung sehe ich allerdings auch andere Wege:

- Durch entsprechendes Design die Anzahl der möglichen
  fehlerträchtigen String-Umwandlungsstellen auf ein Minimum
  reduzieren und dort mit den normalen Python-Mitteln arbeiten. Das
  kann bspw. bedeuten, dass du für Schnittstellen, die immer mit
  Unicode arbeiten, Wrapper schreibst und in deiner eigenen Anwendung
  nur Byte-Strings verwendest. Eine Variante dieses Vorschlags ist ...

- Ausgaben eben nicht mit bspw. print erledigen, sondern eine eigene
  API verwenden, die Konvertierungsfehler ignoriert bzw. eigene
  Konvertierungsregeln umsetzt. (Ich weiß, dass das vielleicht nicht so
  einfach ist.)

- Einen Patch für eine konkrete Python-Implementierung, bspw. CPython,
  schreiben und für Leute, die ähnliche Probleme haben wie du, zum
  Download anbieten. Ein Fork, wie du ihn in deiner Mail in den Raum
  stellst, ist m. E. sicher übertrieben, es sei denn, du willst Python
  in eine grundsätzlich andere Richtung weiterentwickeln.

Viele Grüße
 Stefan