[Python-de] Jahresendrant: Python und die Featuritis

holger krekel pyth at devel.trillke.net
Tue Dec 31 14:00:41 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:
> 
> - 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 oben genannte liste enthaelt IMO keine exotische Features.  Welche
findest du exotisch?

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

wird es.  Zum Beispiel hat Michael Hudson die interpreter-schleife
optimiert und das wird wohl im zweiten 2.3 alpha-release drin sein. 

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

was hat das mit der weiterentwicklung einer sprache zu tun?  Ich finde
das python-dev team ist fuer 2.3 ziemlich konservativ.  siehst doch
wie ein maintenance release aus.  Selbst programme auf python1.5 sind
doch meist noch voll lauffaehig mit heutigen Python versionen. 

> Ich wünsche mir für Python eigentlich drei Dinge:
> 
> A) ein *deutliche* Geschwindigkeitsverbesserung

Kennst du PSYCO oder ggf. auch Pyrex? 

> B) eine *stark* verbesserte Möglichkeit, die Speicherverwaltung zu
> kontrollieren

du meinst, wenn ich dein spaeteres beispiel richtig deute, dass du
den Platzverbrauch fuer executables unter windows minimiert sehen
moechtest? 

> C) eine *sicheres* rexec-Modul

das ist allerdings relativ hoffnungslos.  im gegenteil, es kann sein,
dass es in zukunft deprecated wird.  Du koenntest ggf. mal das security
package von zope3 probieren (in C und ziemlich standalone). 

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

genau. 

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

ist es zu langsam fuer deine zwecke?  schon mal getestet? 

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

das logging modul funktioniert soweit ich weiss ganz gut.  was ist also 
das *konkrete* problem. Irgendwelche theoretischen Probleme sind doch
uninteressant :-)

nichts fuer ungut & guten rutsch,

    holger




More information about the Python-de mailing list