[Python-de] Jahresendrant: Python und die Featuritis

Stefan Schwarzer sschwarzer at sschwarzer.net
Tue Dec 31 18:39:18 EST 2002


Hallo Gerson,

Gerson Kurz wrote:
> 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:

Zum Thema "exotische" Erweiterungen:

> - Verbesserte Unterstützung für die verschiedenen Newline-Kennungen (\r,
> \r\n, \n)

Halte ich für sehr sinnvoll, um Plattformunabhängigkeit zu fördern.

> - Neue eingebaute Funktion enumerate()

Das entsprechende Idiom habe ich schon oft genutzt; enumerate füllt eine echte
Lücke, nicht nur für "4 bis 5 Beispielprogramme".

> - Eine Klasse fürs Logging in der Standard-Bibliothek

Wird bei uns in einem Projekt eingesetzt. Ist klasse!

> - Datentyp bool

Meines Erachtens hätten es die Konstanten True und False, wie in Python 2.2.1+
getan.

> - Erweiterte Slices-Syntax

Ich bin natürlich kein Hellseher, aber ich denke, hier werden sich Anwendungen
finden, wenn sich mehr Python-Programmierer(innen) an dieses Feature gewöhnen.

> 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 ich dich jetzt nicht missverstehe, ist das doch eher ein Ruf nach besserer
Dokumentation und nicht nach weniger Möglichkeiten in neuen Python-Versionen?

> wenn z.B. Redhat weiter 1.5 ausliefert?

Ich denke nicht, dass man Python aus Rücksicht auf RedHat-User nicht weiterent-
wickeln sollte. Und wie von Holger gesagt: Wenn du willst, kannst du für Python
1.5.2 programmieren, und wenn du dabei ein bisschen aufpasst, laufen die Programme
auch mit den neueren Python-Versionen.

> 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.

Wenn du einen "universellen" Interpreter verwendest, braucht der tendenziell
natürlich mehr Platz als ein spezialisiertes Programm, das nur die benötigten
Funktionen linkt. Aber je mehr spezielle Programme du entwickelst und auslieferst,
umso mehr "lohnt" sich das Python-System bei insgesamt gleicher Qualität.

> 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

Genau, _theoretisch_. :-) In vielen Fällen mag das auch zutreffen. Aber lies auch
bitte den Artikel von Martin Fowler:
http://www.martinfowler.com/articles/yetOptimization.pdf

> 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.

Genau (bis auf "coole Features").

> Ein anderes Beispiel: das neue logging modul, nach eigener Aussage "nicht
> für Geschwindigkeit optimiert".

Das ist wohl so zu verstehen, dass andere Eigenschaften höhere Priorität bei
der Entwicklung hatten/haben als Geschwindigkeit. Es heißt ja _nicht_, dass
das Modul mit der Einstellung "Geschwindigkeit ist völlig egal" entwickelt
wurde.

 > 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.

Vielleicht in der Laufzeit, aber in der Entwicklung ...?

 > Ich benutze ein Modul ja nicht, damit mein Programm
> irgendwelchen theoretischen Überlegungen genügt, sondern damit es
> *funktioniert*.

In unserem Projekt funktioniert das Logging-Modul vorzüglich.

> 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 ;)

Ich möchte weder auf Garbage Collection noch auf Exception Handling verzichten;
das sind für mich sogar ganz erhebliche Vorzüge gegenüber bspw. C (wobei sogar
in C99 Exception Handling drin ist, oder?).

Tut mir leid, falls das jetzt dumm rüberkommt, aber soweit ich sehe, ist Python
vielleicht die falsche Sprache für dich. Wenn du mehr Kontrolle willst, dann
nimm doch einfach C/C++. Python ist eben auf andere Prioritäten zugeschnitten
als C/C++, und ich fände es nicht vernünftig, ja, gerade absurd, Pythons Stärken
(z. B. Garbage Collection und Exception Handling) für mehr Geschwindigkeit oder
Low-level-Kontrolle zu opfern.

> 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.

Hm, ich denke, dass die Speicherverwaltung von Python weitaus mehr Probleme
vermeidet als schafft. Im Prinzip forderst du hier das, wogegen du oben wetterst:
Weil es einige wenige Programme/Anwendungen gibt, die von einem Feature
profitieren würden, möchtest du es in der allgemeinen Python-Distribution sehen.

> 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.

Reg' dich bitte nicht so auf, o. k.? :-) Über den bool-Typ wurde sowohl auf der
Python-dev-Liste als auch auf comp.lang.python ausgiebigst diskutiert. Es gibt
sowohl Vor- als auch Nachteile; zu sagen, dass der bool-Typ unnütz ist, ist
m. E. etwas übertrieben. ;-)

Was du wohl sagen wolltest, ist, dass _du_ gut auf den bool-Typ verzichten kannst,
aber das muss nicht für jeden gelten.

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

Dem schließe ich mich an. :-)

Viele Grüße
  Stefan





More information about the Python-de mailing list