Zusammenfassung

Die meisten CPython-Tracker-Probleme werden als Verhalten oder Verbesserung klassifiziert. Die meisten Verhaltens-Patches werden für bestehende Versionen auf Branches zurückportiert. Verbesserungs-Patches sind auf den Default-Branch beschränkt, der die nächste Python-Version wird.

Dieses PEP schlägt vor, die Beschränkung der Anwendung von Verbesserungen für IDLE-Code, der sich in …/Lib/idlelib/ befindet, zu lockern. In der Praxis würde dies bedeuten, dass IDLE-Entwickler Patches nicht klassifizieren oder deren Klassifizierung nicht vereinbaren müssten, sondern sich stattdessen darauf konzentrieren könnten, was für IDLE-Benutzer und die zukünftige IDLE-Entwicklung am besten ist. Es würde auch bedeuten, dass IDLE-Patches nicht unbedingt in "Bugfix"-Änderungen und Verbesserungsänderungen aufgeteilt werden müssten.

Das PEP würde für Änderungen an bestehenden Funktionen und die Hinzufügung kleiner Funktionen gelten, wie z. B. solche, die einen neuen Menüeintrag erfordern, aber nicht unbedingt für mögliche größere Neuschreibungen wie den Wechsel zu thematisierten Widgets oder Tabbed Windows.

Motivation

Dieses PEP wurde durch Kontroversen sowohl im Tracker als auch in der PyDev-Liste über das Hinzufügen von Ausschneiden, Kopieren und Einfügen zu Rechtsklick-Kontextmenüs angestoßen (Issue 1207589, eröffnet 2005 [1]; PyDev-Thread [2]). Die Funktionen waren als Tastenkombinationen verfügbar, aber nicht im Kontextmenü. Es ist Standard, zumindest unter Windows, dass sie verfügbar sein sollten, wenn anwendbar (ein schreibgeschütztes Fenster hätte nur Kopieren), damit Benutzer nicht zur Tastatur wechseln müssen, nachdem sie Text zum Ausschneiden oder Kopieren oder einen Schnittpunkt zum Einfügen ausgewählt haben. Das Kontextmenü wurde erst 10 Tage vor der Hinzufügung der neuen Optionen dokumentiert (Issue 10405 [5]).

Normalerweise wird Verhalten als Fehler bezeichnet, wenn es mit einer als korrekt erachteten Dokumentation kollidiert. Aber wenn es keine Dokumentation gibt, was ist der Standard? Wenn der Code seine eigene Dokumentation ist, sind die meisten IDLE-Probleme auf dem Tracker Verbesserungsprobleme. Wenn wir die vernünftige Erwartung des Benutzers substituieren (die natürlich selbst Gegenstand von Meinungsverschiedenheiten sein kann), sind viele weitere Probleme Verhaltensprobleme.

Bei Kontextmenüs waren sich die Leute über den Status der Ergänzungen uneinig – Bugfix oder Verbesserung. Selbst Leute, die es als Verbesserung bezeichneten, waren sich uneinig darüber, ob der Patch zurückportiert werden sollte. Dieses PEP schlägt vor, die Meinungsverschiedenheit über den Status irrelevant zu machen, indem es eine liberalere Zurückportierung als für andere Standardbibliotheksmodule explizit erlaubt.

Python hat viele fortschrittliche Funktionen, ist aber auch für seine einfache Handhabung für Anfänger bekannt [3]. Eine wichtige Python-Philosophie ist „Batteries Included“, die sich am besten in der Python-Standardbibliothek mit vielen Modulen zeigt, die normalerweise nicht in anderen Programmiersprachen enthalten sind [4]. IDLE ist eine wichtige „Batterie“ im Python-Werkzeugkasten, da sie es Anfängern ermöglicht, schnell loszulegen, ohne eine Drittanbieter-IDE herunterladen und konfigurieren zu müssen. IDLE repräsentiert das Engagement der Python-Community, die Verwendung von Python als Unterrichtssprache sowohl innerhalb als auch außerhalb formaler Bildungseinrichtungen zu fördern. Die empfohlene Lernerfahrung ist, dass ein Anfänger mit IDLE beginnt. Dieses PEP und die Arbeit, die es ermöglicht, werden es der Python-Community ermöglichen, diese Lernerfahrung mit IDLE hervorragend zu gestalten, indem IDLE zu einem einfachen Werkzeug für Anfänger wird, um mit Python zu beginnen.

Begründung

Personen verwenden IDLE hauptsächlich durch Ausführen der grafischen Benutzeroberfläche (GUI-Anwendung), anstatt durch direktes Importieren der effektiv privaten (undokumentierten) Implementierungsmodule in idlelib. Unabhängig davon, ob sie die Shell, den Editor oder beides verwenden, glauben wir, dass sie mehr von der Konsistenz über die neuesten Versionen der aktuellen Python-Versionen profitieren werden als von der Konsistenz innerhalb der Bugfix-Releases für eine Python-Version. Dies gilt insbesondere dann, wenn bestehendes Verhalten eindeutig unbefriedigend ist.

Wenn Leute den Standard-Interpreter verwenden, funktioniert das vom Betriebssystem bereitgestellte Frame für alle Python-Versionen gleich. Wenn beispielsweise Microsoft die Eingabeaufforderungs-GUI aktualisieren würde, wären die Verbesserungen unabhängig davon vorhanden, welche Python-Version darin ausgeführt würde. Ähnlich verhält es sich, wenn man Python-Code mit dem Editor X bearbeitet: Verhaltensweisen wie das Rechtsklick-Kontextmenü und das Such-Ersetzungsfeld hängen nicht von der bearbeiteten Python-Version oder sogar von der bearbeiteten Sprache ab.

Der Vorteil für IDLE-Entwickler ist gemischt. Einerseits ist das Testen von mehr Versionen und möglicherweise die Anpassung eines Patches, insbesondere für 2.7, mehr Arbeit. (Natürlich besteht die Option, nicht alles zurückzuportieren. Für Issue 12510 wurden einige Änderungen an Calltips für Klassen aufgrund von Problemen mit Old-Style-Klassen nicht in den 2.7-Patch aufgenommen [6].) Andererseits kann das „Bike-Shedding“ eine Energiequelle sein. Wenn die offensichtliche Lösung für einen Fehler wie eine Verbesserung aussieht, ist das Schreiben eines separaten Bugfix-only-Patches mehr Arbeit. Und das Auseinanderdriften des Codes zwischen den Versionen erschwert zukünftige Multi-Version-Patches.

Diese Probleme werden durch das Dialogfeld Suchen und Ersetzen veranschaulicht. Es gab früher eine Ausnahme für bestimmte Benutzereingaben [7]. Die nicht abgefangene Ausnahme führte zum Beenden von IDLE. Zumindest unter Windows erfolgte das Beenden lautlos (kein sichtbarer Traceback) und sah wie ein Absturz aus, wenn IDLE normal von einem Symbol gestartet wurde.

War das ein Fehler? IDLE Hilfe (im aktuellen Hilfemenü) besagt nur „Ersetzen… Öffnet ein Dialogfeld zum Suchen und Ersetzen“, und ein Feld *wurde* geöffnet. Es ist im Allgemeinen kein Fehler, wenn eine Bibliotheksmethode eine Ausnahme auslöst. Und es ist im Allgemeinen kein Fehler, wenn eine Bibliotheksmethode eine von ihr aufgerufene Funktion auslösende Ausnahme ignoriert. Wenn wir also die „Code = Dokumentation“-Philosophie in Abwesenheit detaillierter Dokumentation anwenden würden, könnte man sagen „Nein“.

Es ist jedoch auf jeden Fall störend, wenn IDLE beendet wird, obwohl es das nicht muss. Daher waren wir vier uns einig, dass dies verhindert werden sollte. Aber es blieb die Frage, was stattdessen getan werden sollte? Die Ausnahme abfangen? Die Ausnahme einfach nicht auslösen? Piepen? Ein Fehlermeldungsfeld anzeigen? Oder versuchen, etwas Nützliches mit der Eingabe des Benutzers zu tun? Wäre es eine Verbesserung, einen „Absturz“ durch nützliches Verhalten zu ersetzen, das auf zukünftige Python-Releases beschränkt ist? Sollten IDLE-Entwickler das fragen müssen?

Abwärtskompatibilität

Für IDLE gibt es drei Arten von Benutzern, die sich möglicherweise Gedanken über die Abwärtskompatibilität machen. Erstens sind dies Personen, die IDLE als Anwendung ausführen. Wir haben sie oben bereits besprochen.

Zweitens sind dies Personen, die eines der idlelib-Module importieren. Soweit wir wissen, geschieht dies nur, um die IDLE-Anwendung zu starten, und wir schlagen nicht vor, diese Verwendung zu brechen. Ansonsten sind die Module undokumentiert und im Wesentlichen private Implementierungen. Wenn ein IDLE-Modul als öffentlich und dokumentiert definiert würde und vielleicht in das tkinter-Paket verschoben würde, würde es dann den normalen Regeln folgen. (Die Dokumentation der privaten Schnittstellen zum Nutzen derjenigen, die am IDLE-Code arbeiten, ist ein separates Thema.)

Drittens sind dies Personen, die IDLE-Erweiterungen schreiben. Die garantierte Erweiterungsschnittstelle ist in idlelib/extension.txt angegeben. Diese sollte zumindest in bestehenden Versionen eingehalten und in zukünftigen Versionen nicht leichtfertig geändert werden. Es gibt jedoch eine Warnung, dass „Die Erweiterung nicht viel von diesem [EditorWindow]-Argument erwarten kann.“ Diese Garantie sollte selten ein Problem bei Patches darstellen, und das Problem ist nicht spezifisch für „Verbesserungs“- versus „Bugfix“-Patches.

Wie es der Zufall will, stellte sich nach der Anwendung des Kontextmenü-Patches heraus, dass Erweiterungen, die Elemente zum Kontextmenü hinzufügten (selten), durch den Patch a) ein neues Element zu den Standard-rmenu_specs hinzufügten und b) erwarteten, dass jede rmenu_spec verlängert wurde, kaputt gingen. Es ist nicht klar, ob dies gegen die Garantie verstößt, aber es gibt einen zweiten Patch, der Annahme b) korrigiert. Er sollte angewendet werden, wenn klar ist, dass der erste Patch nicht zurückgenommen werden muss.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.