[Python-de] Jahresendrant: Python und die Featuritis

Gerson Kurz Gerson.Kurz at t-online.de
Tue Dec 31 11:42:18 EST 2002


Ich habe mir heute mal die Zeit genommen, das Vorabdokument zu Python 2.3
durchzulesen. (Siehe http://www.python.org/dev/doc/devel/whatsnew/). Die
neuen Features sind bunt gemischt:

- Eine Klasse für Mengen in der Standard-Bibliothek
- Vereinfachte Generatoren
- Für Sourcecode kann ein Encoding angegeben werden (hallo Unicode)
- Unterstützung von Unicode-Dateinamen für NT
- Verbesserte Unterstützung für die verschiedenen Newline-Kennungen (\r,
\r\n, \n)
- Neue eingebaute Funktion enumerate()
- Eine Klasse fürs Logging in der Standard-Bibliothek
- Datentyp bool
- Callbacks für Codec-Fehler
- Erweiterte Slices-Syntax

Nun sind das alles schöne Sachen, aber: wäre es nicht besser, statt sich auf
ständig neue, noch exotischere Features zu stürzen, die dann von vier oder
fünf Beispielprogrammen genutzt werden aber nicht im RealLife weil: es gibt
ja noch ältere Pythonversionen; wenn statt dessen mal das *bestehende*
optimiert wird? Nimm das Beispiel "Properties": Wieviele Leute hier kennen
die Syntax und benutzen sie? Wieviele Leute kennen den Unterschied zwischen
new-style und old-style classes *wirklich* im Detail, wenn z.B. Redhat
weiter 1.5 ausliefert?

Naja.

Ich wünsche mir für Python eigentlich drei Dinge:

A) ein *deutliche* Geschwindigkeitsverbesserung
B) eine *stark* verbesserte Möglichkeit, die Speicherverwaltung zu
kontrollieren
C) eine *sicheres* rexec-Modul

Zu A kann ich das Beispiel meines pserv.cpl anführen
(http://p-nand-q.com/e/pserv.html). Zwar lies sich die Python-Version in
viel kürzerer Zeit realisieren als die C++ Version (wobei der Unterschied
auch nicht sooo krass ist: da ich auch in C++ natürlich eine
Klassenbibliothek einsetze, die mir viel Arbeit abnimmt), aber sie ist um
ein *vielfaches* größer (zum Vergleich: pserv.cpl in C++: 280 kb, keine
zusätzlichen DLLs, in Python: 546kb plus geschlagene 11.6 mb an runtime!!!!)
und um ein *deutlich* langsamer.

Ich habe es schon bei Java immer als deutliche Heuchelei empfunden, wenn man
von "schneller als C++" spricht. Wenn ich ein gegebenes Programm habe, das
interpretiert wird, dann liegt es in der gottverdammten Natur der Sache, daß
es zumindest theoretisch möglich ist, ein schnelleres native Programm zu
schreiben. Ob das im *allgemeinen* praktikabel ist, ist dahingestellt:
alles, was ich sagen kann, ist, daß es mit ein bisserl C erfahrung für mich
in der Regel tatsächlich praktikabel IST. Die Argumente für Python (und
Java) sollten nicht Geschwindigkeit sein (denn das ist einfach falsch)
sondern Portabilität, leichter wartbarer Code, Spaß am Programmieren, koole
Features und so weiter.

Ein anderes Beispiel: das neue logging modul, nach eigener Aussage "nicht
für Geschwindigkeit optimiert". So ein Scheiss! Das logging-Modul kann auch
noch so "supercoole" xml-buzzword-features haben: wenn es das Programm
runterbremst, nehm ich doch lieber ein starres C-Plugin, das dafür deutlich
weniger Zeit kostet. Ich benutze ein Modul ja nicht, damit mein Programm
irgendwelchen theoretischen Überlegungen genügt, sondern damit es
*funktioniert*.

Vielleicht sollte ich mal eine Liste von features erstellen, auf die ich
verzichten kann, wenn ich dafür kompilierten Code erhalte (wobei, du ahnst
es, Garbage Collection und Exception Handling ganz oben stehen werden ;)

Zu B: Das ist etwas, was ich vieleicht selber schreiben werde: ein Patch,
der einen alloc/free trace schreibt, damit man besser kontrollieren kann,
welche Objekte wann wo oder wo nicht freigegeben werden. Hintergrund ist
mein altes Shicks! Problem mit dem OOM-Killer, das ich trotz allem bisher
immer noch nicht eingrenzen konnte. Das ist doch lächerlich: man hat eine
Programmiersprache, in der man sich angeblich nicht mehr um den Speicher
kümmern muß, und genau da treten dann Probleme mit der Speicherverwaltung
des Betriebssystems auf - und es gibt zudem kaum eine Analysemöglichkeit!
Arg.

Zu C: rexec hat m.W. nach einige Sicherheitslücken "by design", was das
ganze Modul letztlich zu einer eher sinnlosen Spielerei verdammt. Dabei wäre
eine echte Sandbox ein Feature, mit dem Python glänzen könnte. ANSTELLE
EINES SCHIMMLIGEN BOOL-TYPES DEN DIE WELT NICHT BRAUCHT.

So, trotzdem einen guten Rutsch, und viel Spaß in 2003,
Gerson







More information about the Python-de mailing list