Wie kann ich prüfen, ob eine Liste leer ist?

Question

Zum Beispiel, wenn Sie das folgende übergeben:

a = []

Wie kann ich überprüfen, ob a leer ist?

Answer 1

Eine leere Liste wird bei der Wahrheitswertprüfung selbst als falsch angesehen (siehe python-dokumentation ):

a = []
if a:
     print "not empty"

@Daren Thomas

EDIT: Ein weiterer Punkt gegen das Testen der leeren Liste als Falsch: Was ist mit Polymorphismus? Man sollte sich nicht darauf verlassen eine Liste eine Liste ist. Sie sollte einfach quaken wie eine Ente - wie wollen Sie deine duckCollection dazu bringen, zu quaken ''Falsch'', wenn sie keine Elemente hat?

Ihre duckCollection sollte implementieren __nonzero__ o __len__ damit die if a: ohne Probleme funktioniert.

Answer 2

Patricks (akzeptierte) Antwort ist richtig: if not a: ist der richtige Weg, dies zu tun. Harley Holcombe's Antwort ist richtig, dass dies im PEP 8 Style Guide steht. Aber keine der Antworten erklärt, warum es eine gute Idee ist, das Idiom zu befolgen - selbst wenn Sie persönlich finden, dass es nicht explizit genug ist oder Ruby-Benutzer verwirrt oder was auch immer.

Python-Code und die Python-Gemeinschaft haben sehr starke Idiome. Wenn Sie sich an diese Idiome halten, ist Ihr Code für jeden, der sich mit Python auskennt, leichter zu lesen. Und wenn Sie gegen diese Idiome verstoßen, ist das ein starkes Signal.

Es stimmt, dass if not a: unterscheidet nicht zwischen leeren Listen und None oder numerisch 0, oder leere Tupel, oder leere benutzererstellte Auflistungstypen, oder leere benutzererstellte Nicht-ganz-Sammlungstypen, oder NumPy-Arrays mit einem Element, die als Skalare mit falschen Werten fungieren, usw. Und manchmal ist es wichtig, das explizit zu machen. Und in diesem Fall, wissen Sie qué die Sie explizit angeben möchten, so dass Sie genau darauf testen können. Zum Beispiel, if not a and a is not None: bedeutet "alles Falsche außer Keinem", während if len(a) != 0: bedeutet "nur leere Sequenzen - alles andere als eine Sequenz ist hier ein Fehler" usw. Damit testen Sie nicht nur genau das, was Sie testen wollen, sondern signalisieren dem Leser auch, dass dieser Test wichtig ist.

Aber wenn Sie nichts haben, worüber Sie explizit sprechen können, etwas anderes als if not a: ist eine Irreführung des Lesers. Sie signalisieren etwas als wichtig, obwohl es nicht wichtig ist. (Vielleicht machen Sie den Code auch weniger flexibel oder langsamer oder was auch immer, aber das ist alles weniger wichtig). Und wenn Sie Gewöhnlich den Leser so in die Irre zu führen, wenn Sie dann hacer Wenn Sie eine Unterscheidung treffen müssen, wird sie unbemerkt bleiben, weil Sie in Ihrem gesamten Code "Wolfsgeheul" gemacht haben.

Answer 3

Warum überhaupt prüfen?

Niemand scheint sich mit der Infragestellung Ihrer brauchen um die Liste überhaupt erst einmal zu testen. Da Sie keinen zusätzlichen Kontext angegeben haben, kann ich mir vorstellen, dass Sie diese Prüfung vielleicht gar nicht benötigen, aber mit der Listenverarbeitung in Python nicht vertraut sind.

Ich würde behaupten, dass die am pythonischsten ist es, überhaupt nicht zu prüfen, sondern nur die Liste zu bearbeiten. Auf diese Weise wird es das Richtige tun, egal ob es leer oder voll ist.

a = []

for item in a:
    <do something with item>

<rest of code>

Dies hat den Vorteil, dass alle Inhalte von a , ohne jedoch eine spezifische Prüfung auf Leere zu verlangen. Wenn a leer ist, wird der abhängige Block nicht ausgeführt und der Interpreter springt zur nächsten Zeile.

Wenn Sie das Feld tatsächlich auf Leere prüfen müssen:

a = []

if !a:
    <react to empty list>

<rest of code>

ist ausreichend.

Answer 4

len() ist eine O(1)-Operation für Python-Listen, -Strings, -Dicts und -Sets. Python merkt sich intern die Anzahl der Elemente in diesen Containern.

JavaScript hat einen ähnlichen Begriff von wahr/falsch .

Answer 5

Ich hatte geschrieben:

if isinstance(a, (list, some, other, types, i, accept)) and not a:
    do_stuff

Ich bin mir nicht sicher, ob das daran lag, dass die Leser die Strategie ablehnten oder die Antwort in der vorgelegten Form nicht hilfreich war. Ich tue so, als sei es Letzteres, denn - was auch immer als "pythonisch" gilt - dies ist die richtige Strategie. Es sei denn, Sie haben bereits ausgeschlossen oder sind bereit, Fälle zu behandeln, in denen a ist, zum Beispiel, False benötigen Sie einen Test, der restriktiver ist als nur if not a: . Sie könnten etwas wie dieses verwenden:

if isinstance(a, numpy.ndarray) and not a.size:
    do_stuff
elif isinstance(a, collections.Sized) and not a:
    do_stuff

der erste Test ist eine Antwort auf die obige Antwort von @Mike. Die dritte Zeile könnte auch ersetzt werden durch:

elif isinstance(a, (list, tuple)) and not a:

wenn Sie nur Instanzen bestimmter Typen (und deren Untertypen) akzeptieren wollen, oder mit:

elif isinstance(a, (list, tuple)) and not len(a):

Sie können auf die explizite Typüberprüfung verzichten, aber nur, wenn der umgebende Kontext bereits sicherstellt, dass a ein Wert des Typs ist, auf den Sie vorbereitet sind, oder wenn Sie sicher sind, dass Typen, auf die Sie nicht vorbereitet sind, zu Fehlern führen werden (z. B. ein TypeError wenn Sie anrufen len für einen Wert, der nicht definiert ist), die Sie bereit sind zu behandeln. Im Allgemeinen scheinen die "pythonischen" Konventionen in diese letzte Richtung zu gehen. Quetschen Sie es wie eine Ente und lassen Sie es einen DuckError auslösen, wenn es nicht weiß, wie man quakt. Sie müssen trotzdem denken Sie sollten sich allerdings Gedanken darüber machen, welche Annahmen Sie treffen und ob die Fälle, auf die Sie nicht vorbereitet sind, wirklich an den richtigen Stellen Fehler machen werden. Die Numpy-Arrays sind ein gutes Beispiel dafür, dass ein blindes Vertrauen in len oder die boolesche Typisierung bewirkt möglicherweise nicht genau das, was Sie erwarten.