Jahresendrant: Python und die Featuritis
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 _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
participants (5)
-
Christian Tismer
-
Gerson.Kurz@t-online.de
-
holger krekel
-
M.-A. Lemburg
-
Stefan Schwarzer