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
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 _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
A) ein *deutliche* Geschwindigkeitsverbesserung B) eine *stark* verbesserte Möglichkeit, die Speicherverwaltung zu kontrollieren C) eine *sicheres* rexec-Modul
Patches welcome ! Oder alternativ: eine Lastschrifterlaubnis, die die PSF dann dazu nutzen kann, diese Sachen umsetzen zu lassen ;-) Guten Rutsch, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
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 _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Stefan Schwarzer wrote:
Hallo Gerson,
Gerson Kurz wrote:
[lange Diskussion] Ok, über Geschmack läßt sich streiten, hier kann keiner wirklich "Recht" haben. Ich selber habe bisweilen auch "gemischte" Gefühle bei der Geschwindigkeit, mit der Python sich weiterentwickelt. Nicht daß dies falsch wäre, aber es ist ungewohnt, und eine Tatsache, daß Guido bis 1.5.2 weitaus konservativer war.
Es gibt sowohl Vor- als auch Nachteile; zu sagen, dass der bool-Typ unnütz ist, ist m. E. etwas übertrieben. ;-)
Das Ding habe ich nie ganz verwunden und lange mit Guido gestritten. Ich finde den Bool-Typ nicht unnütz, aber der Kompromiß ist mir zu faul. Ich sehe ein, daß es ohne diesen überhaupt nicht möglich gewesen wäre. Aber ich hätte es deshalb bleiben gelassen. Damals habe ich argumentiert, "laßt den Unsinn, macht lieber einen richtigen Aufzählungstypen, wobei Bool ein Spezialfall ist". (Ja, ich habe die Rechnung nicht ohne den Wirth gemacht.) Und heute? Heute kommt Bool *und* Aufzählung. Ist mir ein kleinwenig zuviel.
So, trotzdem einen guten Rutsch, und viel Spaß in 2003,
Dem schließe ich mich an. :-)
Und ich genauso! Guten Rutsch (aber nicht wirklich) ciao - chris p.s.: Gerson, ganz vom aktuellen Python abgesehen fände ich es durchaus interessant, ein "Ptn" zu machen: Ein total abgespecktes Minimal-Python mit weniger Features als 1.5.2, sozusagen spartanisch aber aus heutiger Sicht. Elegant wäre es, wenn man von dort zum aktuellen 2.3 wieder "hochkommt" durch gezielten Einsatz von Plugin- Modulen. Vielleicht würde das einen noch klareren Aufbau der Innereien ermöglichen und das Abspecken für embedded-Systeme erleichtern? -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ 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