Hinweis: Obwohl JavaScript für diese Website nicht unbedingt erforderlich ist, werden Ihre Interaktionsmöglichkeiten mit den Inhalten eingeschränkt sein. Bitte aktivieren Sie JavaScript für das volle Erlebnis.

Parade der PEPs

Parade der PEPs

Um den Developer's Day auf der Python10 Konferenz zu beginnen, hielt ich eine Eröffnungsrede, die in dem von mir "Parade der PEPs" getauften Teil gipfelte. Es war ein kurzer Überblick über alle offenen PEPs, bei dem ich meine sehr persönliche und subjektive Meinung zu jeder PEP abgab. Später erkannte ich, dass dies für andere Entwickler von Interesse sein könnte. Ich habe mir während der Konferenz keine Notizen gemacht, daher ist hier eine andere Sammlung von Kommentaren, die ich am 7. März 2002 in einer zweistündigen Sitzung aus dem Stegreif erstellt habe. Ich beabsichtige, dies gelegentlich mit neuen Kommentaren und neuen PEPs zu aktualisieren.

-- Guido van Rossum

PEP 42 - Kleine Funktionswünsche - Hylton

Ehrlich gesagt, dies ist größtenteils ein Sammelbecken für "wünschenswerte" Ideen, die nicht genug Priorität haben, um jemals implementiert zu werden. Es scheint, als ob niemand diesen Stapel durchgeht und eine nette Idee findet, für die er den Code schreibt und einen Patch einreicht. Daher ist eine Idee, die zu PEP 42 verschoben wird, schlechter dran als eine, die sofort abgelehnt wird – sie befindet sich in einer Zombie-Zone, aus der es weder in den Himmel noch in die Hölle entkommen kann. Wie können wir das ändern?

PEP 206 - 2.0 Batteries Included - Zadka

Das ist eine gute Idee. Aber PythonLabs hat nicht die Energie, sie voranzutreiben, und der ursprüngliche Autor auch nicht. Wie können wir daraus eine Gemeinschaftsaktion machen?

PEP 209 - Hinzufügen von mehrdimensionalen Arrays - Barrett, Oliphant

28. März 2002: Meine vorherigen Kommentare basierten auf mehreren Missverständnissen. (Z. B. verhalten sich Slices in Numeric genauso wie in der alten Version und erstellen keine Kopien, wie ich fälschlicherweise dachte.) Zitat von Perry Greenfield:

[...] die neue Version wird immer kompatibler. Tatsächlich sind die wichtigsten verbleibenden Unterschiede
  1. die Regeln für die Koerzion von Unterschieden, wenn Skalare mit Arrays kombiniert werden. Auf der wissenschaftlichen Python BoF gab es Konsens, dass diese Änderung eine gute Sache war.

  2. Typen werden durch Typobjekte anstelle von einzelzeichenigen Codes repräsentiert. Wir haben dies so implementiert, dass es abwärtskompatibel ist, so dass nur sehr wenig alter Python-Code mit diesem beschädigt wird.

  3. Keine Array-Attribute (nämlich shape, flat, real und imag) für Python-Versionen vor 2.2 (wir verwenden das Eigenschaften-Feature, um dies für 2.2 und später zu unterstützen; daher ist es nur inkompatibel mit Numeric mit älteren Python-Versionen)

Es gibt weitere kleinere Unterschiede, aber dies sind die wichtigsten Abwärtskompatibilitätsprobleme auf Python-Ebene. Zwei davon sollten für die meisten Benutzer von Python 2.2 oder später kein Problem darstellen. Es hat eine Reihe wichtiger Erweiterungen, aber dies ist kein Kompatibilitätsproblem. Wahrscheinlich die größten Hürden für die Akzeptanz sind

  1. Eine inkompatible C-API. Wir können Werkzeuge bereitstellen, um die Anpassung von C-Code zu erleichtern, aber wir können sie nicht automatisch machen.

  2. Ein Mangel an Bibliotheken. Wir beginnen jetzt mit der Dokumentation der API, mit Beispielen für die Hinzufügung von C-Code und mit einigen Standardbibliotheken. Es muss genügend Unterstützung in Bibliotheken (einschließlich Plotting) geben, bevor es eine kritische Masse an Funktionalität gibt, die die Leute zum Wechsel bewegt (außerhalb der Astronomie, diese werden durch unsere Bibliotheken, die numarray verwenden, angetrieben)

  3. Langsamere Leistung für kleine Arrays. Da mehr davon in Python geschrieben ist, ist es für kleinere Arrays um Größenordnungen langsamer (aber für große Arrays (> 1 MB) genauso schnell oder schneller). Optimierung ist in unseren Plänen, wird aber erst abgeschlossen sein, wenn wir die Bibliotheken ausgefüllt und das Sicherheitsproblem (das fast abgeschlossen ist) behoben haben.

  4. Aufgrund von 1) und 2) nutzen es noch nicht viele Leute (einige sind beschäftigt und finden Numeric für ihren Zweck geeignet; es braucht mehr als nur seine Verfügbarkeit, damit sie es ausprobieren und ihre Meinung abgeben.)

[zur Aufnahme in den Python-Kern]

Nun, es ist immer noch unser Ziel und wir arbeiten darauf hin (wir schauen uns sogar die Konvertierung der Dokumentation in den Python-Standard an). Es gibt ein Entwurfs-Handbuch. Ich stelle mir vor, dass es ein Jahr dauern wird, bis es einen signifikanten Wechsel der Community zur Nutzung gibt (vorausgesetzt, wir sind erfolgreich darin, sie dazu zu bewegen).

Andererseits glaube ich nicht, dass dieser Zeitplan zwangsläufig der Treiber dafür sein sollte, wann (oder ob) er in den Kern aufgenommen wird. Er könnte vorher in den Kern aufgenommen werden (sie haben unterschiedliche Namen und können nebeneinander existieren) oder lange danach. Ich denke, diese Entscheidung sollte auf einer etwas anderen Grundlage getroffen werden.

Paul Dubois schickte mir eine E-Mail zur Unterstützung von Perrys Nachricht und kündigte an, dass er bald ein Numarray-Benutzer für eine bestimmte Anwendung sein wird. Paul erwähnt auch die C-API als einziges unangenehmes Problem. Er glaubt nicht, dass das Leistungsproblem für kleine Arrays ein großes Problem darstellt.

Basierend auf diesem Feedback erwarte ich, dass diese PEP sich langsam, aber stetig weiterentwickeln wird. Ich erwarte, dass die Autoren mir irgendwann einen Patchsatz zur Verfügung stellen werden, um ihre Codebasis in den Python CVS-Baum zu integrieren. Ob dies für Python 2.3 oder später sein wird, kann ich nicht sagen.

PEP 215 - String-Interpolation - Yee

Ich gehe nicht davon aus, dass die Debatte hier jemals zu einem klaren Ergebnis führen wird. Manche Leute halten es für einen klaren Fall von YAGNI (You Ain't Gonna Need It - Du wirst es nie brauchen), während andere denken, dies sei das wichtigste fehlende Feature für Anfänger. Ich weiß nicht, wer Recht hat. Selbst wenn es ein benötigtes Feature ist, ist die Syntax problematisch: das erste $ in

    print $"The area of a $x by $y rectangle is $z"

ist sehr fragwürdig, aber keine der Alternativen, die ich bisher gesehen habe (z. B. i"...") sieht auch sehr gut aus. Wir können nicht einfach immer die String-Interpolation in Literalen einschalten, da dies bestehenden Code brechen würde. Vielleicht würde "from __future__ import interpolation" die Interpolation in String-Literalen aktivieren? (Nur in Literalen!)

Es gibt auch die Frage, ob beliebige Ausdrücke erlaubt werden sollen, wie z.B.

    print "The area is ${x*y}"

PEP 216 - Docstring-Format - Zadka

Dies hat sehr wenig Inhalt. Vielleicht sollte es zurückgezogen werden? Es gibt mehrere andere PEPs, die sich mit Docstrings befassen, insbesondere 256-258, die mir viel besser gefallen.

PEP 228 - Überarbeitung von Pythons numerischem Modell - Zadka, van Rossum

Das ist viel zu viel "Py-in-the-sky" (utopisch). Es gibt viel zu viele ungelöste Probleme, und viele werden in der PEP nicht einmal erwähnt. Ich denke, sie sollte abgelehnt werden; vielleicht könnte in Zukunft, wenn Interesse besteht, eine Arbeitsgruppe oder SIG (Special Interest Group) gegründet werden, um dieses Thema eingehender zu untersuchen.

PEP 237 - Vereinheitlichung von Ganzzahlen und langen Ganzzahlen - Zadka, van Rossum

Diese wurde bereits akzeptiert, und wir sollten Phase B1 in Python 2.3 implementieren. Muss ich mehr sagen?

PEP 239 - Hinzufügen eines Rational-Typs zu Python - Zadka

Wie bei 228 denke ich, dass dies keine realistische PEP ist, sondern nur eine Sammlung offener Fragen. Ein Rational-Typ scheint mehr Probleme zu schaffen, als er löst.

Vielleicht, nur *vielleicht* könnte es einen effizienten Rational-Typ geben, der in C (natürlich mit Python-Longs) in einem Erweiterungsmodul implementiert ist. Aber das ist nur eine Frage harter Arbeit, und niemand scheint daran interessiert zu sein. In der Zwischenzeit, wenn Sie rationale Zahlen benötigen, gibt es viele Implementierungen in reinem Python (einschließlich Demo/classes/Rat.py).

PEP 240 - Hinzufügen eines Rational-Literals zu Python - Zadka

Angesichts meiner Kommentare zu 239 schlage ich vor, dies abzulehnen.

PEP 242 - Numerische Arten - Dubois

Niemand außer dem Autor scheint daran interessiert zu sein, dies weiterzuverfolgen. Persönlich halte ich die Idee für nicht besonders Pythonisch – der Trend geht zu weniger numerischen Typen, nicht zu mehr (siehe PEP 237). Ich glaube, der Autor hat gesagt, dass es besser wäre, die PEP zurückzuziehen.

PEP 243 - Mechanismus zum Hochladen von Modul-Repositories - Reifschneider

Klar, nett, aber das sollte eine Gemeinschaftsaktion sein. Vielleicht bringt Kapils Projekt für Modul-Repositories (Gideon, /usr/local/WWW/ftp.python.org/pub/www.python.org/sigs/catalog-sig) neues Leben hinein?

Ich denke, das Problem hier ist nicht so sehr Software, sondern (a) die Einrichtung eines Servers (oder einer Reihe von Replikaten), der von der gesamten Gemeinschaft genutzt werden kann, und (b) die Mobilisierung der Gemeinschaft, ihren gesamten Code im Repository einzureichen.

Ein weiteres Problem ist die Überprüfung. Ich denke, CPAN hat dies auch nicht vollständig gelöst (angesichts der Anzahl von Beschwerden, die ich über nicht funktionierende Pakete höre). Woher wissen Sie, welche Beiträge gut sind? Downloads zählen? Ein Formular "dieses Paket bewerten"?

Was plant der ursprüngliche Autor zu tun?

PEP 245 - Python Interface Syntax - Pelletier

Jim Fulton hat gesagt, dass diese PEP verfrüht war. Ich stimme zu. Sie führt ein neues Schlüsselwort 'interface' ein, und ich bin noch nicht überzeugt, dass dies notwendig ist. Andererseits sieht die Art und Weise, wie dies derzeit in Zope geschieht, auch hässlich aus, so dass möglicherweise etwas benötigt wird. Ich denke, dass wir zu einem späteren Zeitpunkt, wenn wir mehr Erfahrung mit der Verwendung von Interfaces haben (insbesondere in Zope 3), zu dieser PEP zurückkehren und sehen werden, wie viel davon wir verwenden können. Vielleicht sollte es einen Sonderstatus "eingefroren" geben, der bedeutet, dass nicht abgelehnt, aber auch nicht kurzfristig in Betracht gezogen wird? Aber mit einer anderen Bedeutung als "Py-in-the-sky" – diese PEP hat zumindest viele konkrete Vorschläge und untersucht die Konsequenzen.

PEP 246 - Objekt-Adaptation - Evans

Ich habe nie verstanden, worum es in dieser PEP ging, bis Alex Martelli es mir erklärte. Ich denke, es ähnelt einer Operation in Zope 3, die nach einem Adapter für ein bestimmtes Objekt sucht, das ein bestimmtes Interface implementiert. Wenn das Objekt selbst das Interface implementiert, wird es selbst zurückgegeben; andernfalls wird eine Tabelle registrierter Adapter systematisch durchsucht, um den am besten geeigneten Adapter zu finden.

Aber das ist alles, was ich über das Thema weiß, und ich denke, es sollte eine nette Idee bleiben, bis wir eine standardisierte Art haben, über Interfaces zu sprechen. Daher denke ich, dass dies zumindest so lange den Status "eingefroren" (siehe oben) haben wird wie PEP 245.

Ich muss zugeben, dass ich die PEP nie ganz gelesen habe und schon gar nicht die Spezifikation oder die Beispielimplementierung gelesen und verstanden habe, also liege ich vielleicht immer noch daneben.

PEP 254 - Klassen besser wie Typen aussehen lassen - van Rossum

Diese PEP war dazu gedacht, Änderungen an der klassischen Klassenimplementierung zu beschreiben, die sie näher an neue Klassen heranführen würden. Ich habe mit dieser Arbeit noch nicht begonnen, und ich denke, vielleicht ist sie nicht notwendig – die klassische Klassenimplementierung kann genauso gut bleiben, wie sie ist, bis sie einfach in Python 3000 entfernt wird. Irgendwann, wenn wir glauben, dass die meisten Benutzer sowieso neue Klassen verwenden, sollten wir Warnungen für die Verwendung von alten Klassen hinzufügen. Die PEP könnte verwendet werden, um den Zeitplan für diese Warnungen zu beschreiben. Aber vorher sollten wir erst sicherstellen, dass die gesamte Standardbibliothek (und die Demos und Werkzeuge) neue Klassen verwenden. Und das wird nicht einmal in Python 2.3 passieren. Außerdem könnte dies Benutzercode brechen, der eine bestimmte Standardklasse unterklassifiziert, z. B. wenn ein Benutzer eine Unterklasse definiert, die von Koerzionen abhängt, die von neuen Klassen nicht unterstützt werden.

PEP 256 - Framework für die Verarbeitung von Docstrings - Goodger

PEP 257 - Docstring-Konventionen - Goodger, van Rossum

PEP 258 - DPS Generische Implementierungsdetails - Goodger

Ich werde diese zusammen besprechen. Ich glaube, David Goodger leistet gute Arbeit und ich sehe immer noch häufige Beiträge von ihm im Doc-Sig. Aber ich habe diese Arbeit überhaupt nicht verfolgt. Da dies die Sprache nicht beeinflusst, sondern nur eine Konvention, ist mir das nicht besonders wichtig.

PEP 262 - Datenbank installierter Python-Pakete - Kuchling

Ich glaube, das war ein Distutils-Projekt "Py-in-the-sky"? Vielleicht sollte das einfach jemand implementieren; ich habe keine Einwände dagegen, aber ich selbst verspüre keinen besonderen Bedarf.

PEP 263 - Definition von Python-Quellcode-Kodierungen - Lemburg

Dieses wird sehr bald eingecheckt. Martin und Marc-Andre klären die Implementierung. Wenn sie bereit sind, werde ich es wohl einfach genehmigen. Es gab ernsthaften Widerstand von einem externen Experten, Stephen Turnbull, der möchte, dass wir die Sprache rein in Bezug auf UTF-8 definieren und Kodierungen als standortspezifische (?) Hooks implementieren. Aber niemand stimmte ihm zu, und ich habe selbst geantwortet und gesagt, dass ich denke, es ist am besten, es auf MALs Weise zu tun.

PEP 265 - Sortieren von Wörterbüchern nach Wert - Griffin

Dies ist eine kleine Idee, die für ihren Vorschlagenden sehr wichtig ist, aber meiner Meinung nach versucht, ein Problem zu lösen, das besser auf andere Weise gelöst wird, z. B. indem man Anfängern den richtigen Algorithmus/das richtige Idiom beibringt. Ich bemerke, dass die PEP eine schludrige Sprache verwendet, z. B. sie spricht von "Sortieren eines Wörterbuchs", während das Wörterbuch selbst nie sortiert wird – die PEP schlägt nur Methoden vor, die die Elemente oder Schlüssel in sortierter Reihenfolge zurückgeben.

Die PEP leidet auch unter mangelnder Eindeutigkeit: Sie schlägt eine ganze Reihe von Alternativen vor, aus denen ich wohl diejenige auswählen soll, die mir am besten gefällt. Mich wieder zum Bösewicht machen. :-)

Schließlich scheint das vorgeschlagene optionale Argument "reversed=<bool>" absolut anwendungsspezifisch zu sein.

Ich würde dies gerne ablehnen, da es kein allgemeines Problem auf eine allgemeine Weise löst, sondern nur die Wörterbuch-API verstopft. Ich würde lieber dict.popitem(key) hinzufügen.

PEP 266 - Optimierung des Zugriffs auf globale Variablen/Attribute Montanaro

PEP 267 - Optimierter Zugriff auf Modul-Namensräume - Hylton

PEP 280 - Optimierung des Zugriffs auf Globals - van Rossum

Diese drei sollten zusammen betrachtet werden; höchstens eine davon kann implementiert werden (oder vielleicht eine Hybridlösung). Ich möchte, dass eine davon schließlich implementiert wird, weil ich denke, dass sie einen großen Leistungsvorteil haben könnte: nicht nur die Vermeidung von Wörterbuch-Lookups für Globals und Builtins, sondern auch die Erkennung bestimmter Builtins im Parser und die Generierung von Code, der weiß, was das Builtin tut, wie ein Opcode für len(x) und spezieller Code für "for i in range(x, y, z)".

Ich denke, Montanaros Vorschlag ist zu komplex. Hyltons Version gefällt mir etwa genauso gut wie meine eigene; seine Version hat einige optionale Features (wie Unterstützung für Attribute von Globals, die "module.attribute" bezeichnen), die meiner Meinung nach den zusätzlichen Aufwand nicht wert sind.

Auf der letzten PythonLabs-Sitzung haben wir beschlossen, zuerst etwas viel weniger Ambitioniertes zu tun und zu sehen, ob vor 2.3 Zeit bleibt, mehr zu tun, nachdem das erledigt ist. Das Weniger Ambitionierte ist die Umstrukturierung des Compilers, die Verwendung eines viel geeigneteren abstrakten Syntaxbaums und die Einführung expliziter Mehrfachdurchgänge. Ich prognostiziere, dass allein dies vor dem 2.3 Beta1 (17. Juli) kaum zu schaffen ist.

PEP 268 - Erweiterte HTTP-Funktionalität und WebDAV - Stein

Ich bin dafür, aber das ist Bibliotheksentwicklungsarbeit, und das werde ich nicht tun.

Es scheint, als hätte der Autor den Ball fallen gelassen und niemand hat ihn aufgehoben. Es gibt einen tatsächlichen Prototyp, der im Verzeichnis sandbox/Lib (seltsamer Name) vom September 2001 eingecheckt wurde; vielleicht sollten wir den Autor unter Druck setzen, die Arbeit abzuschließen, oder ihn fragen, worauf er wartet.

PEP 269 - Pgen-Modul für Python - Riehl

Ich weiß, dass Martin von Loewis das nicht mag (wegen seiner mangelnden Allgemeinheit, z. B. gibt es keine Möglichkeit, den Lexer zu ändern, außer der Definition der Menge der reservierten Wörter), aber ich denke, es könnte für Leute, die mit Python-ähnlichen Sprachen experimentieren (z. B. Python-Präprozessoren, die neue Schlüsselwörter und Syntax hinzufügen), nützlich sein. Da pgen eng an die Python-Distribution gebunden ist, ist es sinnvoll, dass eine Erweiterung, die pgen dem Python-Programmierer zur Verfügung stellt, ebenfalls in der Python-Distribution enthalten sein sollte.

Wir sollten also den Autor fragen, ob er plant, sie zu implementieren. Wenn nicht, sollte sie wahrscheinlich mangels Interesse fallen gelassen werden.

PEP 270 - uniq-Methode für Listenobjekte - Petrone

Gleiche Geschichte wie bei PEP 265. Wie die kämpfenden Cookbook-Einträge zu diesem Thema beweisen, ist dies in voller Allgemeinheit viel schwieriger zu tun, als es scheint. Die PEP ist unvollständig: Sie spezifiziert nicht einmal die erforderliche Semantik! Und warum ist die Implementierung des Autors nicht enthalten, wenn sie nur 20 Zeilen lang ist?

Ich schlage vor, dies abzulehnen, um dem Autor Arbeit zu ersparen (er sollte seine Implementierung trotzdem offenlegen).

PEP 273 - Module aus Zip-Archiven importieren - Ahlstrom

Dieses Konzept gefällt mir. Ich habe die PEP oder die vorgeschlagene Implementierung nicht im Detail studiert, daher weiß ich nicht, ob sie immer das Richtige tut. Ich hoffe, dass sie es in 2.3 schaffen wird.

PEP 274 - Dict Comprehensions - Warschau

Wenn wir Diktat-Comprehensions einführen *würden*, sagt diese PEP alles, was gesagt werden muss. Aber ich will das für Python 2.3 nicht einmal in Erwägung ziehen; ich halte es für ein viel zu geringfügiges Feature.

Es wäre viel einfacher, dies zu übernehmen, wenn es eine funktionierende Implementierung in Form eines Patches gäbe.

Manchmal wäre es schön, wenn solche Dinge über hygienische Makros oder eine andere Art von Präprozessor oder was auch immer definiert und aus einem Modul importiert werden könnten, anstatt größere Hacks im Parser, Compiler für Bytecode und virtueller Maschine zu erfordern.

PEP 275 - Umschalten auf mehrere Werte - Lemburg

Ich bin immer noch nicht überzeugt, dass wir eine switch-Anweisung brauchen, und die vorgeschlagene Syntax hat Probleme: z. B. warum nur Konstanten? Warum keine Bereiche zulassen? Außerdem schlägt sie viele verschiedene Alternativen vor, ohne eine auszuwählen.

Die erste vom PEP vorgeschlagene Alternative fügt jedoch keine neue Syntax hinzu, sondern schlägt lediglich vor, dass der Parser ein bestimmtes gängiges Muster erkennt und dafür besseren Code generiert. Dem bin ich nicht abgeneigt, vorausgesetzt, es kann gezeigt werden, dass der generierte Code entweder signifikant schneller, signifikant kleiner oder beides ist. Dieses Projekt wäre wahrscheinlich viel einfacher nach der Umstrukturierung des Compilers, die oben in den Kommentaren zu den PEPs 266, 267, 280 vorgeschlagen wurde.

PEP 276 - Einfacher Iterator für ganze Zahlen - Althoff

Ich habe den Fehler gemacht, dem Autor zu sagen, dass ich das hässlich finde. Was auch immer die Worte waren, ich finde, es widerspricht dem Pythonischen. Für mich

    for i in 12:
        print i

sieht nicht richtig aus. Vielleicht

    for i in len(L):
        print i, L[i]

ist attraktiv, aber irgendwie denke ich einfach nicht, dass dies die richtige Lösung ist.

PEP 277 - Unicode-Dateinamenunterstützung für Windows NT - Hodgson

Ich kenne den Status davon nicht, aber ich glaube, dies ist bereits implementiert oder zumindest kurz vor der Implementierung? Ist es unter den Deutschen umstritten?

PEP 278 - Universelle Newline-Unterstützung - Jansen

Ich habe Jack eine Menge Teufelsadvokat-Fragen geschickt. Das Problem ist real, und ich möchte, dass es gelöst wird, aber ich bin besorgt, dass dies zu sehr ein Hack ist. Hier ist die Liste

  • Was zum Teufel ist ein source()-Aufruf?
  • Warum nicht auch die Möglichkeit unterstützen, den Trenner für Ausgabedateien festzulegen?
  • Der 't'-Modus kollidiert mit der Verwendung dieses Modus unter Windows, um explizit den Standard-Textübersetzungsmodus aufzurufen.
  • Warum kann 't' nicht zusammen mit '+' verwendet werden? Ich meine, der Textmodus unter Windows unterstützt '+' AFAIK.
  • Wie interagiert dies mit xreadlines? Mit "for line in file"?
  • Warum sich mit einer Kompilierungszeitoption begnügen, die standardmäßig deaktiviert ist? Das ist ein Problem; Leute, die sie aktivieren, schreiben Code, der den 't'-Modus verwendet, und stellen dann fest, dass er nicht portabel ist.
  • Sie sagen, dass der 't'-Modus von import verwendet wird. Was ist mit dem Parsen von Quellcode aus einer Zeichenkette? Was ist mit Unicode-Zeichenketten?
  • Ich glaube, ich brauche mehr Klärung zu Ihrer Bemerkung über Sperren. Wenn die Implementierung missbraucht werden kann, um Core-Dumps zu erstellen, bin ich nicht dafür.

PEP 279 - Verbesserte Generatoren - Hettinger

28. März 2002: Der Autor hat meinen Rat befolgt und die Idee der wiederanlaufbaren Iteratoren entfernt, die ich in einem früheren Kommentar als böse bezeichnet hatte. Hier sind meine aktuellen Kommentare

  1. Neues Builtin: indexed()

    Ich mag die Idee, eine Möglichkeit zu haben, über eine Sequenz und ihren Index gleichzeitig zu iterieren. Es ist in Ordnung, wenn dies ein Builtin ist.

    Ich mag den Namen "indexed" nicht; Adjektive sind keine guten Funktionsnamen. Vielleicht iterindexed()?

    Ich mag die Argumente start und stop nicht. Wenn ich Code wie diesen sehe

         for i, j in iterindexed("abcdefghij", 5, 10): print i, j
    würde ich erwarten, dass er druckt
         5 f
     6 g
     7 h
     8 i
     9 j
    während die Spezifikation in der PEP drucken würde
         5 a
     6 b
     7 c
     8 d
     9 e

    Sehr verwirrend. Ich schlage vor, die start/stop-Argumente zu entfernen, **oder** die Spezifikation zu ändern zu

         def iterindexed(sequence, start=0, stop=None):
         i = start
         while stop is None or i < stop:
             try:
                 item = sequence[i]
             except IndexError:
                 break
             yield (i, item)
             i += 1

    Dies reduziert die Gültigkeit auf nur Sequenzen (im Gegensatz zu allen iterierbaren Sammlungen), hat aber den Vorteil, dass iterindexed(x, i, j) über x[i:j] iteriert, während die Indexsequenz range(i, j) meldet – sonst nicht so einfach.

    Die vereinfachte Version ist immer noch attraktiv, da sie die Übergabe beliebiger Iteratoren ermöglicht

         def iterindexed(collection):
       i = 0
       it = iter(collection)
       while 1:
         yield (i, it.next())
         i += 1
  2. Generator-Comprehensions

    Ich denke nicht, dass es den Aufwand wert ist. Ich erwarte, dass es viel Arbeit erfordert, es in den Code-Generator einzubauen: Es muss ein separates Code-Objekt erstellt werden, um ein Generator zu sein. Listen-Comprehensions sind inline, daher erwarte ich, dass der Generator-Comprehensions-Code-Generator nicht viel mit dem Listen-Comprehensions-Code-Generator gemeinsam hat. Und das für etwas, das nicht so häufig ist und leicht durch das Schreiben einer 2-Zeilen-Hilfsfunktion erledigt werden kann. Anders ausgedrückt, der ROI (Return on Investment) ist nicht hoch genug.

  3. Generator-Ausnahmepassierung

    Hier scheint die PEP am schwächsten zu sein. Es gibt keine wirkliche Motivation ("Dies ist ein echtes Manko" zählt nicht :-)). Es gibt keinen Hinweis, wie es implementiert werden sollte. Das Beispiel hat eine "return log"-Anweisung im Generator-Körper, die derzeit illegal ist, und ich kann nicht herausfinden, wohin dieser Wert zurückgegeben werden würde. Das Beispiel sieht so aus, als bräuchte es keinen Generator, und wenn es ihn bräuchte, wäre es einfach, den Generator zu stoppen, indem man ein globales "stop bitte"-Flag setzt und noch einmal next() aufruft. (Wenn Sie Globals nicht mögen, machen Sie den Generator zu einer Methode einer Klasse und das Stopp-Flag zu einer Instanzvariable.)

PEP 281 - Schleifenzähler-Iteration mit range und xrange Hetland

Eine Alternative zu irange() aus PEP 212 (die in der abgelehnten Liste ist, aber keinen Text enthält, der erklärt, warum sie abgelehnt wurde). Solange wir eine Notation FOO(sequence) einführen werden, die eine (lazy oder anderweitig) Version von range(0,len(sequence)) zurückgibt, denke ich, dass die Verwendung von FOO==range verwirrender ist als alles andere. Das heißt, wenn wir das tun müssen, erfinden wir einen neuen Namen dafür.

PEP 282 - Ein Protokollsystem - Mick

Ich habe danach gefragt und es noch nicht einmal angesehen. Aber es gefällt mir schon jetzt! Ich hoffe, das kann in 2.3 implementiert werden.

PEP 284 - Ganzzahlige for-Schleifen - Eppstein, Ewing

Noch eine weitere Möglichkeit, die Tatsache anzugehen, dass einige Leute

    for i in range(10):

zu hässlich finden. Mein Hauptkritikpunkt hierbei ist, dass

    for 0 <= i < 10:

die Indexvariable in die Mitte und nicht direkt nach dem for-Schlüsselwort setzt. Und im Fall, dass die untere Grenze eine Variable ist, ist das für den Gelegenheitsleser verwirrend

    for i <= j < k:

ähnlich aussieht wie

    for i in j, k:

aber in einem Fall ist der Schleifenzähler j, im anderen Fall i.

Das Gute an dieser PEP ist, dass sie alle früheren PEPs zitiert und kommentiert, die versucht haben, dieses Problem zu lösen (204, 212, 276 und 281).

Ich denke, dass der aktuelle Parser-Generator stark missbraucht werden müsste, um die beiden syntaktischen Alternativen zuzulassen

    for <target_list> in <expression_list>

und

    for <expression> <comparison> <target> <comparison> <expression>

weil eine <target_list> mit <expression> <comparison> beginnen kann.

Abschließende Bemerkungen

Puh! Das ist alles. Nun, es gibt ein paar PEPs in der verlassenen Kategorie, die vielleicht einen Kommentar verdient hätten, aber ich werde warten, bis jemand sie wiederbelebt. Wir sollten definitiv eine klarere Unterscheidung zwischen abgelehnten und aufgeschobenen PEPs treffen. Und keine abgelehnte PEP sollte ohne Erklärung für die Ablehnung bleiben.