Zusammenfassung

Dieses Dokument beschreibt den Entwicklungs- und Veröffentlichungsplan für Python 2.3. Der Plan konzentriert sich hauptsächlich auf PEP-große Elemente. Kleine Funktionen können bis einschließlich der ersten Beta-Version hinzugefügt werden. Fehler können bis zur endgültigen Veröffentlichung behoben werden.

Es wird mindestens zwei Alpha-Versionen, zwei Beta-Versionen und eine Release Candidate geben. Zwischen Alpha- und Beta-Versionen liegen mindestens 4 Wochen (außer wenn eine Notfall-Version zur Korrektur eines Fehlers in der vorherigen Version erforderlich ist; dann zählt die Fehlerkorrektur-Version nicht). Zwischen Release Candidates liegen mindestens eine Woche (wobei Fehlerkorrekturen wieder ausgenommen sind).

Release Manager

Barry Warsaw, Jeremy Hylton, Tim Peters

Abgeschlossene Funktionen für 2.3

Diese Liste ist nicht vollständig. Sehen Sie in Doc/whatsnew/whatsnew23.tex in CVS nach weiteren Informationen und natürlich Misc/NEWS für die vollständige Liste.

• Tk 8.4 Update.
• Der bool-Typ und seine Konstanten, True und False (PEP 285).
• PyMalloc wurde stark erweitert und ist standardmäßig aktiviert.
• Universelle Zeilenende-Unterstützung (PEP 278).
• PEP 263 Definieren von Python-Quellcode-Kodierungen, Lemburg

  Implementiert (zumindest Phase 1, die alles ist, was für 2.3 geplant ist).

• Erweiterte Slice-Notation für alle eingebauten Sequenzen. Der Patch von Michael Hudson wurde nun vollständig eingecheckt.
• Beschleunigung von Listeniterationen durch Füllen von tp_iter und andere Tweaks. Siehe https://bugs.python.org/issue560736; auch für xrange und Tupel.
• Timeout-Sockets. https://bugs.python.org/issue555085
• Phase B0 der int/long-Integration (PEP 237). Dies bedeutet die Ausgabe einer FutureWarning über Situationen, in denen hex oder oct Konvertierungen oder Linksshifts einen anderen Wert für einen int als für einen long mit demselben Wert zurückgeben. Die Semantik ändert sich in Python 2.3 *nicht*; das wird in Python 2.4 geschehen.
• Entfernen von SET_LINENO aus allen Code-Objekten (Bereitstellung einer anderen Möglichkeit zum Setzen von Debugger-Breakpoints). Dies kann pystone um >5% beschleunigen. https://bugs.python.org/issue587993, jetzt eingecheckt. (Leider ist die pystone-Beschleunigung nicht eingetreten. Was ist passiert?)
• Schreiben einer pymemcompat.h, die Leute mit ihren Erweiterungen bündeln und dann die Speicher-Schnittstelle von 2.3 mit allen Pythons im Bereich 1.5.2 bis 2.3 verwenden können. (Michael Hudson hat Misc/pymemcompat.h eingecheckt.)
• Hinzufügen eines neuen Konzepts, „Pending Deprecation“, mit der zugehörigen Warnung PendingDeprecationWarning. Diese Warnung wird normalerweise unterdrückt, kann aber durch eine geeignete -W Option aktiviert werden. Nur wenige Dinge nutzen dies derzeit.
• Warnen, wenn tp_compare eines Erweiterungstyps etwas anderes als -1, 0 oder 1 zurückgibt. https://bugs.python.org/issue472523
• Warnen bei Zuweisung an None (in verschiedenen Formen).
• PEP 218 Hinzufügen eines integrierten Set-Objekttyps, Wilson

  Alex Martelli trug eine neue Version von Greg Wilsons Prototyp bei, und ich habe diese erheblich überarbeitet. Sie ist jetzt als Modul sets in der Standardbibliothek enthalten, obwohl sich einige Details bis zur ersten Beta-Version noch ändern können. (Es gibt derzeit keine Pläne, dies zu einem integrierten Typ zu machen.)

• PEP 293 Callbacks für Codec-Fehlerbehandlung, Dörwald

  Vollständig implementiert. Die Fehlerbehandlung in unicode.encode oder str.decode kann nun angepasst werden.

• PEP 282 Ein Logging-System, Mick

  Vinay Sajips Implementierung wurde paketiert und importiert. (Dokumentation und Unit-Tests noch ausstehend.) https://bugs.python.org/issue578494

• Ein modifizierter MRO (Method Resolution Order) Algorithmus. Der Konsens ist, dass wir C3 übernehmen sollten. Samuele Pedroni hat eine Entwurfsimplementierung in C beigesteuert, siehe https://bugs.python.org/issue619475 Dies wurde nun eingecheckt.
• Ein neuer Parser für Kommandozeilenoptionen. Greg Wards Optik-Paket (http://optik.sf.net) wurde übernommen und in ein einzelnes Modul namens optparse konvertiert. Siehe auch https://pythonlang.de/sigs/getopt-sig/
• Ein standardmäßiger datetime-Typ. Dies begann als Wiki: http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage. Ein Prototyp wurde in nondist/sandbox/datetime/ codiert. Tim Peters hat die C-Implementierung fertiggestellt und eingecheckt.
• PEP 273 Module aus Zip-Archiven importieren, Ahlstrom

  Implementiert als Teil der Implementierungsarbeit für PEP 302.

• PEP 302 Neue Import-Hooks, JvR

  Implementiert (obwohl die Veröffentlichung 2.3a1 einige Fehler enthielt, die nach der Veröffentlichung behoben wurden).

• Ein neues Pickling-Protokoll. Siehe PEP 307.
• PEP 305 (CSV-Datei-API von Skip Montanaro et al.) ist dabei; dies ist das csv-Modul.
• Raymond Hettings itertools-Modul ist dabei.
• PEP 311 (Vereinfachte GIL-Akquisition für Erweiterungen von Mark Hammond) wurde in Beta 1 aufgenommen.
• Zwei neue PyArg_Parse*() Formatcodes, 'k' gibt ein vorzeichenloses C long int zurück, das die unteren LONG_BIT Bits des Python-Arguments empfängt, ohne Bereichsprüfung abschneidend. 'K' gibt ein vorzeichenloses C long long int zurück, das die unteren LONG_LONG_BIT Bits empfängt, ohne Bereichsprüfung abschneidend. (SF 595026; Thomas Heller hat diese Arbeit geleistet.)
• Eine neue Version von IDLE wurde vom IDLEfork-Projekt (http://idlefork.sf.net) importiert. Der Code befindet sich jetzt im Paket idlelib in der Standardbibliothek, und das Skript idle wird von setup.py installiert.

Geplante Funktionen für 2.3

Zu spät, um hier noch mehr zu erledigen.

Laufende Aufgaben

Die folgenden sind laufende TO-DO-Elemente, an denen wir ohne Hoffnung auf eine Fertigstellung zu einem bestimmten Datum arbeiten sollten.

• Dokumentation: Vervollständigung der Distributions- und Installationshandbücher.
• Dokumentation: Vervollständigung der Dokumentation für Klassen im neuen Stil.
• Durchsicht des Demos/-Verzeichnisses und Aktualisierung, wo erforderlich (Andrew Kuchling hat viel davon erledigt)
• Neue Tests.
• Behebung von Doc-Bugs auf SF.
• Entfernen der Verwendung von veralteten Funktionen im Kern.
• Veraltete Funktionen angemessen dokumentieren.
• Veraltete C-APIs mit Py_DEPRECATED markieren.
• Module veralten lassen, die nicht gepflegt werden, oder vielleicht eine neue Kategorie für Module „Nicht gepflegt“ erstellen.
• Allgemein viel Aufräumen, damit es einfacher ist, vorwärtszukommen.

Offene Themen

Es gibt einige Probleme, die vor der endgültigen Veröffentlichung (und vorzugsweise vor der ersten Beta-Version) mehr Arbeit und/oder Nachdenken erfordern könnten: Keine verbleibenden Probleme.

Funktionen, die es nicht in Python 2.3 geschafft haben

• Der Import-Lock könnte eine Überarbeitung vertragen. (SF 683658.)
• Set-API-Probleme; ist das Set-Modul perfekt?

  Ich gehe davon aus, dass es gut genug ist, um die Optimierung einzustellen, bis wir mehr breite Benutzererfahrung gesammelt haben.

• Eine schönere API zum Öffnen von Textdateien, die die hässliche (in den Augen mancher) „U“-Modus-Flagge ersetzt. Es gibt einen Vorschlag, einen neuen integrierten Typ textfile(filename, mode, encoding) zu haben. (Sollte er nicht auch ein *bufsize*-Argument haben?)

  Dito.

• Neue Widgets für Tkinter???

  Hat jemand Zeit dafür? *Gibt es* überhaupt neue Widgets in Tk 8.4? Beachten Sie, dass wir bereits eine bessere Tix-Unterstützung haben (wenn auch noch nicht unter Windows).

• Fredrik Lundhs Basetime-Vorschlag

  http://effbot.org/ideas/time-type.htm

  Ich glaube, das ist jetzt tot.

• PEP 304 (Kontrolle der Erzeugung von Bytecode-Dateien von Montanaro) scheint an Schwung verloren zu haben.
• Für eine Klasse, die innerhalb einer anderen Klasse definiert ist, sollte der __name__ "outer.inner" sein, und das Pickling sollte funktionieren. (SF 633930. Ich bin nicht mehr sicher, ob das einfach oder überhaupt richtig ist.)
• reST wird in Zope3 viel verwendet werden. Könnte es vielleicht ein Standardbibliotheksmodul werden? (Da der Autor von reST es für zu instabil hält, neige ich dazu, dies nicht zu tun.)
• Eine klarere Richtlinie für die Veraltung (insbesondere für Module) festlegen und umsetzen. Zunächst siehe diese Nachricht von Neal Norwitz: https://mail.python.org/pipermail/python-dev/2002-April/023165.html Es scheint unzureichendes Interesse zu geben, dies weiter organisiert voranzutreiben, und es ist nicht besonders wichtig.
• Alternativen für häufige Verwendungen des types-Moduls bereitstellen;

  Skip Montanaro hat einen Proto-PEP für diese Idee veröffentlicht: https://mail.python.org/pipermail/python-dev/2002-May/024346.html

  Es gab keine Fortschritte dabei, soweit ich weiß.

• Verwenden Sie „pending deprecation“ für die Module types und string. Dies erfordert die Bereitstellung von Alternativen für die Teile, die noch nicht abgedeckt sind (z. B. string.whitespace und types.TracebackType). Es scheint, dass wir hier keinen Konsens erzielen können.
• Das buffer-Objekt veralten lassen.
  • https://mail.python.org/pipermail/python-dev/2002-July/026388.html
  • https://mail.python.org/pipermail/python-dev/2002-July/026408.html

  Es scheint, dass dies niemals gelöst werden wird.

• PEP 269 Pgen Modul für Python, Riehl

  (Einige notwendige Änderungen sind vorhanden; das pgen-Modul selbst muss noch reifen.)

• Unterstützung für den lang erwarteten Python-Katalog hinzufügen. Kapil Thangavelu hat eine Zope-basierte Implementierung, die er auf der OSCON 2002 vorgestellt hat. Jetzt brauchen wir nur noch einen Ort, um ihn zu hosten, und eine Person, die ihn vorantreibt. (Einige Änderungen an distutils zur Unterstützung dessen sind zumindest vorhanden.)
• PEP 266 Optimierung des Zugriffs auf globale Variablen/Attribute, Montanaro

  PEP 267 Optimierter Zugriff auf Modul-Namespaces, Hylton

  PEP 280 Optimierung des Zugriffs auf Globale Variablen, van Rossum

  Dies sind im Grunde drei freundliche konkurrierende Vorschläge. Jeremy hat mit einem neuen Compiler kleine Fortschritte gemacht, aber es geht langsam voran und der Compiler ist nur der erste Schritt. Vielleicht können wir den Compiler in dieser Version refaktorieren. Ich bin versucht zu sagen, wir werden nicht den Atem anhalten. In der Zwischenzeit hat Oren Tirosh eine viel einfachere Idee, die die Leistung des Zugriffs auf globale und eingebaute Variablen erheblich steigern könnte, indem sie den Dict-Zugriff optimiert und inline schaltet: http://tothink.com/python/fastnames/

• Lazy-Tracking von Tupeln?
  • https://mail.python.org/pipermail/python-dev/2002-May/023926.html
  • https://bugs.python.org/issue558745

  Ich glaube, wenig Enthusiasmus.

• PEP 286 Erweiterte Argument-Tupel, von Loewis

  Ich hatte keine Zeit, dies gründlich zu überprüfen. Es scheint ein tiefgreifender Optimierungs-Hack zu sein (garantiert auch bessere Korrektheit).

• Machen Sie 'as' zu einem Schlüsselwort. Es ist schon lange ein Pseudo-Schlüsselwort. Zu viel Aufwand, um sich darum zu kümmern.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.