[Python-de] OOP mit Python

Martin v. Loewis martin at v.loewis.de
Mon Dez 29 15:46:18 CET 2003


kgm wrote:

> Aber, fällt es Dir nicht auf, wie oft dazu Fragen auftauchen, auch in 
> c.l.p? Da ja auch häufig von Dir dazu Antworten kommen, müßte es Dir 
> auffallen ;-) 

Das fällt mir schon auf. Ich glaube jedoch, dass das nicht daran liegt,
dass die Python-Implementierung undurchsichtig ist, sondern dass vielen
Entwickler einfach die "richtige" Modellvorstellung fehlt. Sie hatten
bisher nur mit einer einzigen Zeichenkodierung zu tun, und haben deshalb
das Phänomen "Zeichensätze" bisher gar nicht wahr genommen.

Das merkt man an Bemerkungen der Art, dass Byte-Strings "ASCII-Strings"
genannt werden, selbst wenn dort nicht-ASCII-Zeichen vorkommen, die dann
als "Sonderzeichen" bezeichnet werden, usw. Wenn das mentale Modell
"es gibt mehr als einen Zeichensatz" sich verbreitet hat, ist auch
die Python-Implementierung dieses Modells nicht mehr undurchsichtig.

> Und wie sich da lange Diskussionen hin + her entwickeln, 
> die aber eigentlich nicht zu eindeutigen Antworten führen.

Hmm. Wenn diejenigen, die Antworten, das Problem selbst nicht verstehen,
kann das schon durchaus vorkommen. Immer häufiger lese ich aber die
"richtigen" Antworten, die dann *immer* auch eindeutig sind.

> Die Regeln sind, glaube ich, weitgehend klar.
> Du bist aber nicht auf die Ausnahmen+Sonderregeln eingegangen. Gerade 
> das wäre interessant. 

Bin ich. Es gibt die Sonderregel, dass man Bytestrings und
Unicode-Strings "manchmal" kombinieren darf. Darüber hinaus gibt es
in der Sprache keine Sonderregeln in Bezug auf Unicode.

Allerdings muss man zusätzlich noch wissen, welche Parametertypen
und Rückgabetypen irgendwelche Funktionen der Bibliothek haben.
Das muss man einfach auswendig lernen, so, wie man auch gelernt
hat, dass

Integer + Integer ergibt Intger
Integer + Float   ergibt Float
Liste   + Liste   ergibt Liste

> Wie Du hier und da schon erwähnt hast, wurde 
> dies+das aus Gründen der Rückwärtskompatibilität eingebaut, damit alte 
> Scripte weiter laufen. (Stichworte: Tkinter, das mal Bytestrings, mal 
> Unicode zurückgibt, Textdateien, die sich ohne Encoding-Angabe 
> lesen/schreiben lassen. 

Na ja - keine Regel der Sprache, sondern eben der Bibliothek. Die
Bibliothek verändert sich auch stärker als die Sprache selbst.
Gerade in Bezug auf Unicode ist zu erwarten, dass man in Zukunft
Unicode-Strings an Funktionen übergeben darf, die heute nur Bytestrings
akzeptieren; genauso, wie man heute an vielen Stellen long integers
übergeben darf, wo vorher nur ints erlaubt waren.

> Vermutlich noch andere Stellen, die ich noch 
> nicht kenne (achja, was ist mit Filefunktion (open() usw.) bezgl. der 
> Pfad/Filenamen mit Encoding? Irgendwas automatisch?)).

Gute Frage, siehe PEP 277. Seit Python 2.3 kann man auf nahezu allen
Systemen Unicode-Dateinamen übergeben (an nahezu alle Funktionen -
manche wurden vergessen). Dabei wird
1. Unter Win32 das Unicode-API verwendet, also erfolgt gar keine
    Konvertierung. Das bedeutet wiederum, dass
    a) unter NT+ (W2k, WXP, W2k3) die Dateien als Unicode-Folge auf
       dem NTFS abgelegt werden, und
    b) unter W9x die Namen in CP_ACP konvertiert werden (vom
       Betriebssystem)
    Damit kann man im Ergebnis unter NT+ beliebige Unicode-Dateinamen
    verwenden; unter W9x nur die, die in CP_ACP ("mbcs") unterstützt
    sind.
2. auf allen anderen Systemen der Dateiname mittels
    sys.getfilesystemencoding() kodiert. Dieses ergibt sich
    a) unter Max OS X als "UTF-8"
    b) unter Systemen, die nl_langinfo(CODESET) unterstützen,
       entsprechend der locale des Nutzers, und
    c) auf allen anderen Systemen aus dem system default encoding

In Python 2.2 war das etwas anders: Unter Win32 war das file
system encoding immer "mbcs" (man hatte also nur 1b), und sonst
war es immer system default encoding (also 2c); neu in 2.3
sind also 1a), 2a) und 2b).

> Mein Wunsch wäre, eine Liste mit allen diesen Ausnahmen. Das wäre 
> bestimmt sehr hilfreich. Wo genau wird was wegen Rückwärtskompatibel 
> gemacht?

Wie gesagt: Das sind keine Ausnahmen. Ich könnte Deine Frage jetzt
so interpretieren als: "Welche API-Funktionen verarbeiten
Unicode-Strings, und welche geben Unicode-Strings zurück?"

Das würde allerdings eine ziemlich lange Liste werden...

> Die Tkinter-Eigenheit führt zB auch in IDLE zu Bugs. Wenn Unicode doch 
> so klar und "durchsichtig" ist, warum passieren dann sogar den 
> Entwicklern der Sprache solche Fehler?

Aus zwei Gründen: Zum einen, weil man in Python immer testen muss, und
IDLE offenbar zuwenig getestet wurde (in dieser Frage), zum anderen,
weil es historischer Code ist, der früher intern nur Bytestrings
verwendet hat, und nun intern Unicode-Strings verwenden sollte, das
aber nicht einheitlich macht.

Andere Aspekte sind einfach keine Bugs: Das man beispielsweise
im interaktiven Modus von IDLE keine Umlaute eingeben darf, ist
kein IDLE-Bug. Vielmehr ist nicht klar, was die Umlaute an der
Stelle bedeuten sollen, deshalb sind sie nicht erlaubt.

Ciao,
Martin