Shortcirting List Comprehensions [duplizieren]

Question

Shortcirting List Comprehensions [duplizieren]

8

Bei verschiedenen Gelegenheiten wollte ich die Python-Syntax für das Kurzschließen von Listenkompromittierungen oder Generatorausdrücken verwenden.

Hier ist ein einfaches Listenverständnis und das Äquivalent für die Schleife in Python:

%Vor%

Es gibt keine Unterstützung in der Sprache für ein Verständnis, das kurzschließt. Vorgeschlagene Syntax und Entsprechung für die Schleife in Python:

%Vor%

Es sollte mit beliebigen Iterablen funktionieren, einschließlich unendlicher Sequenzen, und kann für die Generatorausdrucksyntax erweiterbar sein. Ich kenne list(itertools.takewhile(lambda x: x != 'potato'), my_list) als Option, aber:

es ist nicht besonders Python - nicht so leserlich wie eine Weile Verständnis
es kann wahrscheinlich nicht so effizient oder schnell sein wie ein CPython-Verständnis
es erfordert einen zusätzlichen Schritt, um die Ausgabe zu transformieren, wohingegen dies direkt in ein Verständnis gebracht werden kann, z. %Code%
selbst der Originalautor scheint es nicht besonders zu mögen .

Meine Frage ist, gab es irgendwelche theoretische Falte darüber, warum es nicht eine gute Idee ist, die Grammatik auf diesen Anwendungsfall zu erweitern, oder ist es einfach nicht möglich, weil Python Entwickler denken, dass es selten nützlich wäre? Es scheint eine einfache Ergänzung zu der Sprache zu sein und ein nützliches Feature, aber ich übersehe wahrscheinlich einige versteckte Feinheiten oder Komplikationen.

Verwandte: dies und das

python list-comprehension generator-expression

wim 05.06.2013, 03:47

quelle

1 Antwort

Tags und Links python list-comprehension generator-expression

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Vollständiger äußerer Join in 2 Datentabellen mit einer Liste von Spalten

score 6 · Accepted Answer

Wie Paul Pugh McGuire feststellte, wurde es in PEP 3142 und abgelehnt von Guido:

Ich wusste nicht, dass es dafür eine PEP gibt. Ich lehne es hiermit ab. Kein Punkt verschwenden mehr Zeit darauf.

Er gibt jedoch keine Erklärungen. In der Mailingliste sind einige der Punkte dagegen:

"[Verständnis] sind eine sorgfältig entworfene 1: 1-Transformation zwischen mehreren verschachtelten Anweisungen und einem einzelnen Ausdruck. Aber dieser Vorschlag ignoriert und bricht das. ( hier )." Das heißt, das Schlüsselwort while entspricht nicht einem while in der expliziten Schleife - es ist nur ein break dort.
"Es macht Python schwieriger zu lernen, weil es noch eine weitere Sache zum Lernen hinzufügt." (Zitat hier )
Es fügt einen weiteren Unterschied zwischen Generatorausdrücken und Listenverständnis hinzu. Es scheint, als käme das Hinzufügen dieser Syntax zum Listenverständnis überhaupt nicht in Frage.

Ich denke, dass ein grundlegender Unterschied zum üblichen Listenverständnis darin besteht, dass while von Natur aus zwingend ist, nicht deklarativ. Es hängt davon ab und diktiert eine Reihenfolge der Ausführung, die nicht von der Sprache (AFAIK) garantiert wird. Ich denke, das ist der Grund, warum es nicht in Haskells Verständnis enthalten ist, von dem Python die Idee gestohlen hat.

Natürlich haben Generatorausdrücke eine Richtung, aber ihre Elemente können vorberechnet werden - wiederum AFAIK. Der erwähnte PEP hat es nur für Generatorausdrücke vorgeschlagen - was einen Sinn ergibt.

Natürlich ist Python sowieso eine Imperativsprache, aber es wird Probleme aufwerfen.

Was ist mit der Auswahl einer nicht geordneten Sammlung?

%Vor%

Sie haben es auch nicht in einfachen for -Schleifen, aber das können Sie nicht durch die Sprache erzwingen. takewhile beantwortet diese Frage, aber es ist eine willkürliche Antwort.

Ein letzter Punkt, beachten Sie, dass Sie aus Konsistenzgründen Unterstützung für dropwhile wünschen. etwas wie

%Vor%

Was noch weniger mit dem äquivalenten for -Konstrukt zusammenhängt, und dieses Mal ist es möglicherweise kein Kurzschluss, wenn my_list nur ein iterabler Wert ist.