Zawsze dają ten sam wynik.
W rzeczywistości not 'ham' in 'spam and eggs'
wydaje się być specjalnie oznaczony wielkością liter, aby wykonać pojedynczą operację „nie w”, a nie operację „w”, a następnie zanegować wynik:
>>> import dis
>>> def notin():
'ham' not in 'spam and eggs'
>>> dis.dis(notin)
2 0 LOAD_CONST 1 ('ham')
3 LOAD_CONST 2 ('spam and eggs')
6 COMPARE_OP 7 (not in)
9 POP_TOP
10 LOAD_CONST 0 (None)
13 RETURN_VALUE
>>> def not_in():
not 'ham' in 'spam and eggs'
>>> dis.dis(not_in)
2 0 LOAD_CONST 1 ('ham')
3 LOAD_CONST 2 ('spam and eggs')
6 COMPARE_OP 7 (not in)
9 POP_TOP
10 LOAD_CONST 0 (None)
13 RETURN_VALUE
>>> def not__in():
not ('ham' in 'spam and eggs')
>>> dis.dis(not__in)
2 0 LOAD_CONST 1 ('ham')
3 LOAD_CONST 2 ('spam and eggs')
6 COMPARE_OP 7 (not in)
9 POP_TOP
10 LOAD_CONST 0 (None)
13 RETURN_VALUE
>>> def noteq():
not 'ham' == 'spam and eggs'
>>> dis.dis(noteq)
2 0 LOAD_CONST 1 ('ham')
3 LOAD_CONST 2 ('spam and eggs')
6 COMPARE_OP 2 (==)
9 UNARY_NOT
10 POP_TOP
11 LOAD_CONST 0 (None)
14 RETURN_VALUE
Na początku myślałem, że zawsze dawały ten sam wynik, ale sam not
w sobie był po prostu logicznym operatorem negacji o niskim priorytecie, który można było zastosować a in b
tak samo łatwo jak każde inne wyrażenie logiczne, podczas gdy not in
był oddzielnym operatorem dla wygody i przejrzystości .
Demontaż powyżej był odkrywczy! Wygląda na to, że chociaż not
jest to oczywiście operator logiczny negacji, formularz not a in b
ma specjalną wielkość liter, więc w rzeczywistości nie używa operatora ogólnego. Daje to not a in b
dosłownie to samo wyrażenie a not in b
, a nie tylko wyrażenie, które daje tę samą wartość.
not x in xs
w dokumentacji.not x in xs
jestnot (x in xs)
. Ale fakt, że jest implementowany przez parsowanie go do dokładnie tego samego kodu bajtowego, cox not in xs
bardzo wyraźnie pokazuje, że muszą one być zawsze identyczne, w przeciwieństwie do rzeczy takich jaknot x == y
vs,x != y
które powinny dawać ten sam wynik, ale nie muszą (w zależności od implementacji__eq__
i__ne__
zaangażowani).not in
jest to preferowane, ponieważ jest bardziej oczywiste i dodali do tego specjalny przypadek.źródło
Mają identyczne znaczenie, ale kontroler przewodnika w stylu pycodestyle w Pythonie (wcześniej nazywany pep8) preferuje
not in
operator w regule E713 :Zobacz także „Python
if x is not None
czyif not x is None
?” za bardzo podobny wybór stylu.źródło
Inni już dali jasno do zrozumienia, że te dwa stwierdzenia są, na dość niskim poziomie, równoważne.
Jednak nie sądzę, aby ktokolwiek jeszcze wystarczająco podkreślił, że skoro to pozostawia wybór Tobie, powinieneś
wybierz formę, która zapewni jak największą czytelność Twojego kodu.
I niekoniecznie tak czytelne, jak to tylko możliwe dla każdego , nawet jeśli jest to oczywiście fajna rzecz do osiągnięcia. Nie, upewnij się, że kod jest dla Ciebie możliwie jak najbardziej czytelny , ponieważ najprawdopodobniej wrócisz do tego kodu później i spróbujesz go przeczytać.
źródło
W Pythonie nie ma różnicy. I nie ma preferencji.
źródło
Składniowo są tym samym stwierdzeniem. Chciałbym szybko stwierdzić, że
'ham' not in 'spam and eggs'
przekazuje jaśniejszy zamiar, ale widziałem kod i scenariusze, w którychnot 'ham' in 'spam and eggs'
przekazuje jaśniejsze znaczenie niż inne.źródło