PEP3003: Lasst uns den Fortschritt 2 Jahre aufhalten

[sma]

Was haltet ihr von PEP 3003, der Idee, für mindstens 2 Jahre die Sprache Python nicht weiter zu entwickeln, mit dem Argument, dass dies den Herstellern alternativer Interpreter etwas Zeit gibt, aufzuholen.

Wahrscheinlich bin ich allgemein zu ungeduldig und eine Sprache, die es schon fast 20 Jahre gibt hat die Zeit und Ruhe, doch es fühlt sich für mich falsch an. Zu erkennen, dass Python 3.x von der Community nicht aufgepickt wird ist eins, dann aber einfach zu sagen, na gut, dann warten wir, wird glaube ich das Problem nicht lösen sondern nur die 2.x-Version noch stärker fixieren.

Was meint ihr?

Stefan

[Pekh]

Prinzipiell halte ich es nicht für die schlechteste Idee. Sollte auf jeden Fall gründlich diskutiert werden.

Ein paar Gedanken, die mir dazu jetzt spontan gekommen sind: Alternative Implementierungen werden immer hinterherhinken. Gründe dafür gibt es viele: Sie haben in der Regel weniger Ressourcen zur Verfügung, und müssen vieles überhaupt erst neu entwickeln, während im Core-Bereich das Meiste schon vorhanden ist und nur angepaßt werden muß. Ich finde es einen feinen Zug, den Entwicklern an diesen Projekten etwas mehr Luft zuzugestehen. Nur: Wenn jetzt für zwei Jahre die Entwicklung angehalten wird, wird der nächste "Schub" wieder ähnlich heftig ausfallen wie der jetzige. Und dann stehen genau diese Entwickler wieder da und können sehen, wo sie bleiben.

Die Idee, die Ressourcen jetzt einmal auf Verbesserungen "hinter den Kulissen" zu konzentrieren, finde ich durchaus gut, aber vielleicht nicht zwei Jahre lang. Man könnte die Stdlib von Ballast befreien und PEP8-Konform machen oder, wie beschrieben, den Interpreter selbst verbessern.

Auch das ein Halt in der Entwicklung eine Anpassung externer Module "erleichtern" würde, ist ein wichtiger Punkt.

Auf der anderen Seite: Eine Sprache, die sich zwei Jahre nicht weiterentwickelt, könnte ins Hintertreffen geraten. Auf der einen Seite haben wir das "Abhängen" der alternativen Interpreter, auf der anderen Seite wird es sicherlich einige Ungeduldige geben, die nicht abwarten können und ihren eigenen Zweig entwickeln. Auch hier besteht die Gefahr einer Zersplitterung. Ähnlich wie bei C oder Pascal könnten bald die verschiedensten Dialekte entstehen, was ich persönlich schade finden würde. Die Balance zu halten dürfte schwierig werden.

Langer Rede kurzer Sinn: Keine Ahnung wie ich dazu stehe Brauche noch mehr Input ...

[lunar]

Geht es nur um die Entwicklung der Sprache, oder um die Entwicklung von ganz Python inkl. der Standardbibliothek?

Die Sprache kann ruhig mal zwei Jahre stillstehen. Es gibt Sprachen, bei denen sich über viel längere Zeiträume kaum etwas getan hat, ohne das es der Verbreitung der Sprache geschadet hätte. Die Standardbibliothek dagegen sollte besser nicht zwei Jahre lang ruhen.

[Pekh]

Geht es nur um die Entwicklung der Sprache, oder um die Entwicklung von ganz Python inkl. der Standardbibliothek?

Die Sprache kann ruhig mal zwei Jahre stillstehen. Es gibt Sprachen, bei denen sich über viel längere Zeiträume kaum etwas getan hat, ohne das es der Verbreitung der Sprache geschadet hätte. Die Standardbibliothek dagegen sollte besser nicht zwei Jahre lang ruhen.

Es geht wohl um die Sprache an sich, da die Standardbibliothek sogar explizit ausgenommen wird.

[BlackJack]

Es steht ja nicht da was genau in den zwei Jahren an "internen" Verbesserungen gemacht wird, aber das die C-API sich explizit ändern darf, könnte ja zum Beispiel bedeuten, dass das GIL bzw. dessen Beseitigung in Angriff genommen werden könnte. Fänd ich nicht schlecht.

[gerold]

der Idee, für mindstens 2 Jahre die Sprache Python nicht weiter zu entwickeln

Hallo!

Das ist meiner Meinung nach seit langem der beste Vorschlag von Guido.

Jede Änderung an der Sprache bedeutet, dass die Programmierer neu lernen müssen um mit der Sprache weiter arbeiten zu können. Es ist aber kein Spaß, sich immer nur weiterbilden zu müssen, damit man in wenigen Jahren noch das Selbe mit der Sprache tun kann, was man jetzt schon kann. Statt sich zu verbessern, muss man lernen um auf dem gleichen Stand zu bleiben. Ganz schön blöd!

Statt dass die Programmiersprache verbessert wird, wird sie verändert. Da gehört unbedingt ein paar Jahre ein Riegel vorgeschoben, damit sich Python intern verbessern kann. Ich hätte es mir nie gedacht, aber ich stoße ab und zu auf richtige Fehler in den mitgelieferten Modulen. Und um den Fragen vorzuwirken: Nein, ich kann keine Bugreports schreiben, da ich nicht Englisch kann. Ich hoffe halt, dass die Bugs mit der nächsten Version ausgebessert werden.

Außerdem kann man, alleine durch ändern der Algorithmen, in einigen Modulen richtig an Geschwindigkeit -- und sehr wichtig, auch an Zuverlässigkeit -- dazu gewinnen. Man sollte wirklich mal, in der Gruppe, Modul für Modul durchgehen und diskutieren, ob und wie man es verbessern kann. Ich spreche hier von Python 2.6. Die Module von Python 3 habe ich mir noch nicht angesehen.

Wir hatten hier im Board mal darüber diskutiert, wie man Zahlen formatiert ausgeben kann. Da wurden Tests gemacht, welche Algorithmen schneller sind. Da wurde darüber diskutiert, wie man es am Besten machen könnte.
Man müsste eine Möglichkeit finden, die Ergebnisse solcher Verbesserungsbemühungen, direkt in Python einfließen lassen zu können. Bei mir scheitert es immer nur am Englisch. Aber es gibt hier genug, die Englisch können, und solche Vorschläge weiterleiten können.

Vielleicht macht man auch hier im Board mal eine Aktion, in der man sich hier im Forum ein Modul pro Monat vornimmt und durchdiskutiert, ob und wie man es besser machen könnte. Man könnte einen Zeitplan aufstellen und wichtige Module vorziehen. Nur eines muss gewährleistet sein --> die ausdiskutierten Quellcode-Vorschläge müssen bei den Python-Entwicklern landen.

So. Genug geschwafelt.

mfg
Gerold

[Pekh]

Ein monatliches Online-Patch-Weekend? Wäre interessant. Es gibt ja z.B. bei den Ubuntuern in Berlin regelmäßige Coding-Sessions. Ich weiß nicht, wie viel ich da beisteuern könnte, aber zumindest kann ich Englisch

[lunar]

@Gerold: Du dramatisierst die Sache über die Maßen. Man muss sich nicht "weiterbilden", um auf dem aktuellen Stand zu bleiben, so umfangreich waren Änderungen zwischen Versionen nie (mal abgesehen von Python 3). Es reicht, sich die Änderungen in der Dokumentation durchzulesen.

Zudem zwingt Dich niemand, neuere Features zu nutzen. Wenn Du weder den Sinn von "with" noch die Vorteile von Dekoratoren sehen möchtest, dann kannst Du auch mit Python 2.6 noch so programmieren, wie Du es mit Python 2.3 getan hast.

Lass aber allen anderen ihren Fortschritt, die einen Sinn in "with" und Dekoratoren sehen, und denen "print" als Funktion lieber ist. Es mag Dir nicht verständlich sein, aber für viele andere ist "with" nicht nur eine Änderung, sondern tatsächlich eine unmittelbare Verbesserung.

[Dav1d]

Fortschritt ist doch nie schlecht, oder?

Fortschritt = fort + Schritt, so eine Art Schritt nach vorne

man kann ihn mitgehen, man kann aber auch noch eine weile auf seiner Position bleiben (nicht ewig, is klar), solange die anderen die mitgegangen sind noch in erreichbarer Entfernung liegen.

[BlackJack]

@Dav1d: Natürlich kann Fortschritt auch schlecht sein. Der Schritt nach vorn muss ja nicht in die richtige Richtung gehen. Getreu nach dem Motto: Gestern standen wir vor dem Abgrund. Heute sicnd wir schon einen guten Schritt weiter.

Java soll ja auch ein Fortschritt sein, nur dass die halt etwas zu weit gegangen sind, in dem Bemühen den Anwender davor zu schützen, sich selbst in den Fuss zu schiessen. Oder einen zu "OOP" zu zwingen.

[Leonidas]

Java soll ja auch ein Fortschritt sein, nur dass die halt etwas zu weit gegangen sind, in dem Bemühen den Anwender davor zu schützen, sich selbst in den Fuss zu schiessen. Oder einen zu "OOP" zu zwingen.

Java ist auch in dem Sinne ein Fortschritt, dass es VMs überhaupt erst marktreif gemacht hat. So kann man sagen dass man die Parrot VM oder Python VM verwendet, also ne VM wie die JVM und inzwischen ist das allgemein Akzeptioert (obwohl das VM-Konzept natürlich schon wesentlich älter ist, Smalltalk und dessen Images fallen einem da spontan ein). Auch die konsequente Verwendung von Unicode ist ein Fortschritt um den Java Python lange Zeit vorraus war.

Natürlich, die Fehler von Java aufzuzählen, das würde auf keine Kuhhaut gehen

[pillmuncher]

Fortschritt ist doch nie schlecht, oder?

"Der Fortschritt ist halt wie ein neuentdecktes Land; ein blühendes Kolonialsystem an der Küste, das Innere noch Wildnis, Steppe, Prärie. Überhaupt hat der Fortschritt das an sich, daß er viel größer ausschaut, als er wirklich ist." - Johann Nepomuk Nestroy, Der Schützling (1847) IV,10

Gruß,
Mick.

[Dav1d]

@Dav1d: Natürlich kann Fortschritt auch schlecht sein. Der Schritt nach vorn muss ja nicht in die richtige Richtung gehen. Getreu nach dem Motto: Gestern standen wir vor dem Abgrund. Heute sicnd wir schon einen guten Schritt weiter.

Java soll ja auch ein Fortschritt sein, nur dass die halt etwas zu weit gegangen sind, in dem Bemühen den Anwender davor zu schützen, sich selbst in den Fuss zu schiessen. Oder einen zu "OOP" zu zwingen.

Jo stimmt auch wieder, aber ohne Fortschritt wo wären wir dann?

@pillmuncher: Das Zitat trifft's

[BlackJack]

@Dav1d: Woanders!?

[gerold]

Zudem zwingt Dich niemand, neuere Features zu nutzen. Wenn Du weder den Sinn von "with" noch die Vorteile von Dekoratoren sehen möchtest, dann kannst Du auch mit Python 2.6 noch so programmieren, wie Du es mit Python 2.3 getan hast.

Hallo lunar!

Ich habe nichts gegen "with". Ich setze es nur ziemlich selten ein, da ich es öfter noch mit Python 2.4 und 2.5 zu tun habe. Und dann darf ich den Code wieder so umschreiben, dass er auch noch mit den älteren Versionen funktioniert. Bei Programmen, die garantiert nur mit Python 2.6> ausgeführt werden, setze ich es zunehmend ein. Das ist ja auch eine "Neuerung" und keine "Änderung". Wer das dazugehörende "contextlib"-Modul versteht und wem nicht vorkommt, dass hier manches etwas zu kompliziert gemacht wurde, kann damit gerne arbeiten.

Auch Dekoratoren fallen in diese Kategorie -- mit dem Unterschied, dass ich Dekoratoren für viele Dinge niemals einsetzen würde. Wer glaubt, dass damit Dinge einfacher geworden sind, soll sie verwenden. Wer aber glaubt, dass es ein einfacher Funktionsaufruf am Ende einer Funktion auch getan hätte, der soll lieber den einfachen Funktionsaufruf am Ende einer Funktion machen. Es macht in meinen Augen einfach keinen Sinn, wenn man etwas zuerst durch den Fleischwolf dreht, nur um danach wieder ein Schnitzel draus zu machen. Aber wie es scheint, stehe ich mit meiner Meinung über Dekoratoren alleine da.
Dass nicht alles "gut" oder "böse" ist, beweisen "@property" oder "@classmethod". Wenn man es also richtig anstellt, dann kann man mit Dekoratoren auch interessante Dinge anstellen, ohne etwas zu verkomplizieren.

Dass "print" eine Funktion geworden ist, damit kann ich leben. Es muss ja nicht alles nach meinem Kopf gehen. Obwohl ich den Sinn dahinter nicht verstehe. Statt "print" zu überschreiben mache ich mir einfach eine Funktion mit einem neuen Namen. Schon ist das Problem, dass "print" nicht überschrieben werden kann, gelöst. Also, was war das Problem mit "print" nochmal? Stattdessen wurde es in meinen Augen unnötigerweise **verändert**.

Was ist mit "%" passiert? Ich kann mich erinnern, dass irgendwo vorgeschlagen wurde, "%" nicht mehr für Stringformatierungen zu verwenden? Kann das sein? Und wenn ja, warum?

Ach ja, da ist es ja:

Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used.

http://docs.python.org/3.1/tutorial/inp ... formatting

``format()`` ist ja nicht schlecht, aber kann mir einer erklären, warum man "%" aus Python entfernen sollte? Ich kann mir das nur so erklären, dass es ein paar Idioten gibt, die alles auf "Teufel komm raus" verändern möchten.

Und jetzt lasse ich es, sonst verliere ich noch meine Ruhe.

lg
Gerold


PS: Bitte versteht mich nicht falsch. Neue Tools können eine riesen Erleichterung sein, wenn sie durchdacht sind. *collections.OrderedDict* ist so ein Fall. Auf das habe ich schon lange gewartet. Besten Dank dafür an Armin und Raymond!

[birkenfeld]

Es steht ja nicht da was genau in den zwei Jahren an "internen" Verbesserungen gemacht wird, aber das die C-API sich explizit ändern darf, könnte ja zum Beispiel bedeuten, dass das GIL bzw. dessen Beseitigung in Angriff genommen werden könnte. Fänd ich nicht schlecht.

Genau da tut sich gerade was: Antoine Pitrou arbeitet an einer etwas anderen Implementierung des GIL; der Witz dabei ist, dass ein Thread nicht mehr genau X Python-Bytecodeinstruktionen abarbeitet, bevor ein Threadswitch erfolgen kann (was ein Problem ist, weil der Zeitbedarf für eine einzelne Instruktion sehr stark variieren kann), sondern eine feste Zeitscheibe bekommt.

Es gibt also immer noch ein Lock, aber es macht multi-threaded Python-Code wenigstens nicht mehr *langsamer*. Details hier: http://mail.python.org/pipermail/python ... 93321.html

[Leonidas]

Wer das dazugehörende "contextlib"-Modul versteht und wem nicht vorkommt, dass hier manches etwas zu kompliziert gemacht wurde, kann damit gerne arbeiten.

Also um ehrlich zu sein, finde ich contextlib ziemlich straightforward. Es gibt das Contextmanager-Protokoll, das mit seinen ``__enter__`` und ``__exit__``-Methoden zwar recht flexibel ist, aber etwas kompliziert. Dann gibt es ``contextlib.contextmanager()`` mithilfe dessen man eine Generator-Funktion zu so einem Contextmanager umbauen kann, vollautomatisch, sogar mit Dekorator. Dann gibt es ``nested()`` was nützlich ist um mehrere Contextmanager gleichzeitig zu betreten, was aber durch Syntaxerweiterungen in 2.7 und 3.1 nicht mehr nötig ist. Schließlich gibt es ``closing()`` das ein Objekt dass ``close()`` anbietet aber kein Contextmanager ist zu einem Contextmanager wrappt.

Ich bin auch nicht 100% zufrieden mit Contextmanagern, weil sie nicht auf den in ihnen gewrappten Context zugreifen können, aber zu Komplex fand ich sie nie. Als ich von ihnen in den What's New-Dokumenten gelesen habe war ich sogar positiv erstaunt wie simpel das ist.

[sma]

Ich freue mich, wie viele Reaktionen ein etwas provokanter Titel erzielen kann.

Ja, Guido will nur die Syntax und die Semantik der "builtins" einfrieren, nicht die Standardbibliothek. Warum aber gerade das helfen soll, verstehe ich nicht. Die Syntax nicht zu ändern hilft nur den Leuten, die einen Syntaxhighlighter bauen wollen. Und selbst da wären neue Schlüsselwörter trivial. Selbiges gilt für Parser. Wenn ich einen Python-Interpreter in Java baue, ist nicht die Syntax mein Problem, sondern die Standardbibliothek. An meinem Interpreter für Python 1.4 habe ich ca. 10 Tage gearbeitet. Das Laufzeitsystem (inbesondere die Semantik der eingebauten Typen) späterer Python-Versionen ist ungleich komplizierter, doch auch da würde ich jetzt schätzen, dass man das in wenigen Wochen nachgebaut hat. Danach heißt es dann verzweifeln, weil es nicht schnell genug ist ;) Erst dann begibt man sich in die Kompatibilitätshölle und muss "endlos" viele teils C-basierte Bibliotheken portieren, wenn man wirklich die letzten 20% schaffen will, damit größere Projekte auch laufen. Das kostet dann mindestens 160% der Zeit.

Und wie das Moratorium dafür sorgen kann, dass die Leute jetzt Python 3.1 als Alternative zu Python 2.x ansehen, erschließt sich mir noch nicht. Dabei wäre doch genau dieses das gewünschte Ziel.

@BlackJack: Java und Fortschritt? Lass dir von jemandem sagen, dessen geliebte Programmiersprache Smalltalk Mitte der 90er von Java verdrängt wurde, dass das ein großer Rückschritt war. Die Richtung des Schritts ist etwas sehr relatives. Für C-Entwickler mag es eine Verbesserung gewesen sein. :)

Stefan

[gerold]

Warum aber gerade das helfen soll, verstehe ich nicht.

Hallo Stefan!

Ich glaube: Es geht nicht um das Technische oder wie genau Guido es formuliert hat, sondern um die Botschaft: "Lasst uns mal eine Zeit lang nichts mehr verändern, sondern nur verbessern!" Welche Begründungen er dafür vorgeschoben hat, ist nebensächlich.

lg
Gerold

[Dav1d]

Warum aber gerade das helfen soll, verstehe ich nicht.

Hallo Stefan!

Ich glaube: Es geht nicht um das Technische oder wie genau Guido es formuliert hat, sondern um die Botschaft: "Lasst uns mal eine Zeit lang nichts mehr verändern, sondern nur verbessern!" Welche Begründungen er dafür vorgeschoben hat, ist nebensächlich.

lg
Gerold

Wenn es so gemeint ist, ist es toll und eine richtig gute Idee