Warum ist ‘True == not False’ ein Syntaxfehler in Python?
Lesezeit: 3 Minuten
Tim Martin
Vergleich von booleschen Werten mit == funktioniert in Python. Aber wenn ich den booleschen Wert anwende not Operator, das Ergebnis ist ein Syntaxfehler:
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True == True
True
>>> False == False
True
>>> True is not False
True
>>> True == not False
File "<stdin>", line 1
True == not False
^
SyntaxError: invalid syntax
>>>
Warum ist das ein Syntaxfehler? Ich würde erwarten not False ein Ausdruck sein, der einen booleschen Wert zurückgibt, und True == <x> überall gültige Syntax sein <x> ist ein Ausdruck mit gültiger Syntax.
Beachten Sie, dass “Wahr ist nicht falsch” ist nicht das gleiche wie “Wahr ist (nicht falsch)”. “ist nicht” ist ein eindeutiger Operator, was “ist nicht identisch mit” bedeutet, während “Wahr ist (nicht falsch)” als “Wahr ist identisch mit der booleschen Negation von False” gelesen wird. Nur eine Bemerkung, denn Ihr Beispiel scheint, als ob Sie annehmen würden, dass beides gleich ist.
– lunaryorn
23. Mai ’11 um 17:12
True == not ist der eigentliche Syntaxfehler, alles danach ist irrelevant.
– dansalmo
28. Dezember ’13 um 23:39
Und fürs Protokoll, das scheitert für beliebig Vergleichsoperator plus not, unabhängig von den verglichenen Typen. True < not False, 3 <= not 2, 'Foo' > not 'False', 3.3 >= not 4.5, {} is not not [], set() == not None und slice() != not lambda: xalle den gleichen Syntaxfehler auslösen. Dies ist nicht beschränkt auf == not und boolesche Werte.
– Martijn Pieters ♦.
31. Januar ’14 um 17:12
Rafe Kettler
Es hat mit … zu tun Operator-Priorität in Python (der Dolmetscher denkt, Sie vergleichen Wahr mit nicht, da == hat eine höhere Priorität als not). Sie benötigen einige Klammern, um die Reihenfolge der Operationen zu verdeutlichen:
True == (not False)
Im Allgemeinen können Sie nicht verwenden not auf der rechten Seite eines Vergleichs ohne Klammern. Ich kann mir jedoch keine Situation vorstellen, in der Sie jemals a . verwenden müssen not auf der rechten Seite eines Vergleichs.
Gibt es einen Grund für die Operator-Priorität oder ist es nur ein dummes “Feature”?
– Jim Clay
23. Mai ’11 um 16:52
Beeindruckend; das ist interessant. Ich kenne keine andere Sprache, die ich kenne, in der die Negation einen so niedrigen Vorrang hat, sicherlich nicht niedriger als die Gleichheit!
– verdesmarald
23. Mai ’11 um 16:54
Logisch Inversion hat in Python niedrige Priorität. Im Gegensatz dazu ist die arithmetische Negation (unär -) und bitweise Inversion (~) haben beide eine recht hohe Priorität.
– ncoghlan
23. Mai ’11 um 17:37
Und natürlich macht es wie fast alles in Python absolut Sinn, da == not beides sieht komisch aus und kann in den meisten Fällen durch ersetzt werden != ohnehin.
– Lennart Regebro
23. Mai ’11 um 18:58
@JimClay Der Grund ist wahrscheinlich die Konsistenz mit anderen Vergleichsoperatoren, bei denen diese Rangfolge imo absolut sinnvoll ist: in if not (foo.x * 2) + 1 < bar du würdest nicht erwarten not (foo.x*2) + 1 um “1 genau wenn (foo.x*2) + 1 == 0 sonst 0” zu bedeuten und es dann mit bar mit “kleiner als” zu vergleichen. Das Negieren von Anweisungen mit “<" ist in einigen Fällen auch besser lesbar als das Negieren von "<" selbst zu ">=”.
– Nearoo
31. Januar ’21 um 9:21
abschalten
Es ist nur eine Frage der Operator-Priorität. Versuchen:
>>> True == (not False)
True
Schau mal rein diese Tabelle der Operator-Prioritäten, das wirst du finden == bindet fester als not, und somit True == not False wird geparst als (True == not) False was eindeutig ein Fehler ist.
Antworten, die behaupten, dass der Grund für True == not False die einen Syntaxfehler darstellen, der mit der Operator-Priorität zu tun hat, sind falsch. Wenn dies der Fall wäre, würde der Ausdruck 2 ** - 1 würde auch einen Syntaxfehler ergeben, was natürlich nicht der Fall ist. Der Vorrang führt nie dazu, dass ein Operator anstelle eines Operanden eingezogen wird.
Der wahre Grund für True == not False ein Syntaxfehler ist, dass es keine Syntaxregel gibt, die a . erzeugen würde Vergleich davon, da
Im Vergleich dazu ist das in Bezug auf die Rangfolge ähnliche Konstrukt 2 ** - 1 nach der Potenzregel
Leistung ::= (await_expr | primär) [“**” u_expr]
hat u_expr nach dem Potenzoperator **, also erlaubt - x auf der rechten Seite.
Vermutlich erwähnenswert wo nottut passt hier rein: an inversion entweder 'not' gefolgt von einem anderen inversion, oder ein comparison. Ein inversion ist der Baustein von a conjunction, das ist der Baustein von a disjunction, die Sie sich im Grunde als eine der drei Grundtypen von vorstellen können expressions (die anderen beiden sind bedingte Ausdrücke und Lambda-Ausdrücke).
– chepner
15. Juli ’21 um 21:24
Python hat eine Operator-Priorität (Dies ist wie Bodmas in Mathematik. Bestimmte Operatoren werden vor anderen berücksichtigt. Beispiel: Multiplikationsoperator wird vor der Addition berücksichtigt). In Python steht ‘==’ vor ‘not’ in der Operator-Priorität. Daher ist in Ihrer Codezeile das erste, was Python analysiert, ‘False == not’. Da dies eine falsche Syntax ist, wird ein Fehler ausgegeben.
Ich denke, was Sie suchen, ist “und nicht”. Dadurch erhalten Sie die gewünschten Ergebnisse. Wenn Ihr boolesches Vergleichsergebnis ein zusammengesetzter boolescher Ausdruck ist, finden Sie hier eine Beispiel-Website Zusammengesetzter boolescher Ausdruck.
>>> True and True
True
>>> True and not True
False
>>> True and not False
True
>>> False and not True
False
>>> False and not False
False
>>> False and False
False
.
1963900cookie-checkWarum ist ‘True == not False’ ein Syntaxfehler in Python?yes
Beachten Sie, dass “Wahr ist nicht falsch” ist nicht das gleiche wie “Wahr ist (nicht falsch)”. “ist nicht” ist ein eindeutiger Operator, was “ist nicht identisch mit” bedeutet, während “Wahr ist (nicht falsch)” als “Wahr ist identisch mit der booleschen Negation von False” gelesen wird. Nur eine Bemerkung, denn Ihr Beispiel scheint, als ob Sie annehmen würden, dass beides gleich ist.
– lunaryorn
23. Mai ’11 um 17:12
True == not
ist der eigentliche Syntaxfehler, alles danach ist irrelevant.– dansalmo
28. Dezember ’13 um 23:39
Und fürs Protokoll, das scheitert für beliebig Vergleichsoperator plus
not
, unabhängig von den verglichenen Typen.True < not False
,3 <= not 2
,'Foo' > not 'False'
,3.3 >= not 4.5
,{} is not not []
,set() == not None
undslice() != not lambda: x
alle den gleichen Syntaxfehler auslösen. Dies ist nicht beschränkt auf== not
und boolesche Werte.– Martijn Pieters
♦.
31. Januar ’14 um 17:12