Zawsze uważałem, że if not x is Nonewersja jest bardziej przejrzysta, ale zarówno przewodnik po stylu Google, jak i PEP-8if x is not None . Czy jest jakaś niewielka różnica w wydajności (zakładam, że nie) i czy jest jakikolwiek przypadek, w którym jedno naprawdę nie pasuje (co sprawia, że ​​drugi jest wyraźnym zwycięzcą mojej konwencji)? *

* Mam na myśli dowolny singleton, a nie tylko None.

... aby porównać singletony takie jak None. Zastosowanie jest lub nie jest.

Nie ma różnicy w wydajności, ponieważ kompilują się do tego samego kodu bajtowego:

Python 2.6.2 (r262:71600, Apr 15 2009, 07:20:39)
>>> import dis
>>> def f(x):
...    return x is not None
...
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (x)
              3 LOAD_CONST               0 (None)
              6 COMPARE_OP               9 (is not)
              9 RETURN_VALUE
>>> def g(x):
...   return not x is None
...
>>> dis.dis(g)
  2           0 LOAD_FAST                0 (x)
              3 LOAD_CONST               0 (None)
              6 COMPARE_OP               9 (is not)
              9 RETURN_VALUE

Stylistycznie staram się unikać not x is y. Chociaż kompilator będzie zawsze traktował to jako not (x is y), ludzki czytelnik może źle zrozumieć konstrukcję jako (not x) is y. Jeśli piszę, x is not ynie ma dwuznaczności.

Zarówno Google, jak i przewodnik po stylu Python to najlepsza praktyka:

if x is not None:
    # Do something about x

Używanie not xmoże powodować niepożądane wyniki.

Patrz poniżej:

>>> x = 1
>>> not x
False
>>> x = [1]
>>> not x
False
>>> x = 0
>>> not x
True
>>> x = [0]         # You don't want to fall in this one.
>>> not x
False

Możesz być zainteresowany tym, do których literałów są oceniane TrueFalse w Pythonie lub w:

• Testowanie wartości prawdy

Edytuj komentarz poniżej:

Właśnie wykonałem kilka testów. not x is Nonenie neguje xnajpierw, a potem w porównaniu do None. W rzeczywistości wydaje się, że isoperator ma wyższy priorytet, gdy jest używany w ten sposób:

>>> x
[0]
>>> not x is None
True
>>> not (x is None)
True
>>> (not x) is None
False

Dlatego not x is Nonewłaśnie, moim zdaniem, najlepiej unikać.

Więcej edycji:

Właśnie wykonałem więcej testów i mogę potwierdzić, że komentarz bukzora jest prawidłowy. (Przynajmniej nie byłem w stanie udowodnić, że jest inaczej).

Oznacza to if x is not None, że ma dokładny wynik jak if not x is None. Poprawiono mnie. Dzięki bukzor.

Jednak moja odpowiedź nadal brzmi: użyj konwencjonalnegoif x is not None .:]

Kod powinien być napisany tak, aby był zrozumiały dla programisty, a na drugim - kompilator lub interpreter. Konstrukcja „nie jest” przypomina angielski bardziej niż „nie jest”.

Python if x is not Nonelub if not x is None?

TLDR: Kompilator kodu bajtowego analizuje je oba x is not None- więc ze względu na czytelność użyj if x is not None.

Czytelność

Używamy Pythona, ponieważ cenimy takie rzeczy, jak czytelność dla człowieka, użyteczność i poprawność różnych paradygmatów programowania nad wydajnością.

Python optymalizuje czytelność, szczególnie w tym kontekście.

Analiza i kompilacja kodu bajtowego

Że not wiąże się słabiej niżis , więc nie ma tu różnicy logicznej. Zobacz dokumentację :

Operatorzy isiis not test tożsamości obiektu: x is yjest prawdą, jeśli i tylko wtedy, gdy xiy są tym samym obiektem. x is not ydaje odwrotną wartość prawdy.

Jest is notto specjalnie przewidziane w Pythonie gramatyce jako poprawa czytelności dla języka:

comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'

Jest to więc również element gramatyki.

Oczywiście nie jest tak samo parsowane:

>>> import ast
>>> ast.dump(ast.parse('x is not None').body[0].value)
"Compare(left=Name(id='x', ctx=Load()), ops=[IsNot()], comparators=[Name(id='None', ctx=Load())])"
>>> ast.dump(ast.parse('not x is None').body[0].value)
"UnaryOp(op=Not(), operand=Compare(left=Name(id='x', ctx=Load()), ops=[Is()], comparators=[Name(id='None', ctx=Load())]))"

Ale wtedy kompilator bajtów faktycznie przetłumaczy not ... isnais not :

>>> import dis
>>> dis.dis(lambda x, y: x is not y)
  1           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                1 (y)
              6 COMPARE_OP               9 (is not)
              9 RETURN_VALUE
>>> dis.dis(lambda x, y: not x is y)
  1           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                1 (y)
              6 COMPARE_OP               9 (is not)
              9 RETURN_VALUE

Więc ze względu na czytelność i używanie języka zgodnie z przeznaczeniem, proszę użyć is not .

Nie używać tego nie jest mądre.

Odpowiedź jest prostsza niż ludzie.

W każdym razie nie ma przewagi technicznej, a „x nie jest y” jest tym, czego wszyscy inni używają , co czyni go wyraźnym zwycięzcą. Nie ma znaczenia, że ​​„wygląda bardziej jak angielski” czy nie; wszyscy go używają, co oznacza, że ​​każdy użytkownik Pythona - nawet chińscy, których język Python nie przypomina - na pierwszy rzut oka zrozumie, gdzie nieco mniej powszechna składnia zajmie kilka dodatkowych cykli mózgowych.

Nie bądź inny tylko dlatego, że jesteś inny, przynajmniej w tej dziedzinie.

is notOperatora jest bardziej korzystny niż negując wyniku isprzyczyn historycznych. „ if x is not None:” czyta podobnie jak angielski, ale „ if not x is None:” wymaga zrozumienia pierwszeństwa operatora i nie czyta jak po angielsku.

Jeśli jest różnica w wydajności, moje pieniądze są na is not, ale prawie na pewno nie jest to motywacja do decyzji o preferowaniu tej techniki. Oczywiście byłoby to zależne od implementacji. Ponieważ isnie można go zastąpić, optymalizacja jakiegokolwiek rozróżnienia powinna być łatwa.

Osobiście używam

if not (x is None):

który jest rozumiany natychmiastowo bez dwuznaczności przez wszystkich programistów, nawet tych, którzy nie są ekspertami w składni języka Python.

if not x is Nonejest bardziej podobny do innych języków programowania, ale if x is not Nonezdecydowanie brzmi dla mnie wyraźniej (i jest bardziej poprawny gramatycznie w języku angielskim).

To powiedziawszy, wydaje mi się, że jest to dla mnie bardziej preferencja.

Wolałbym bardziej czytelną formę x is not y niż myślałem, jak w końcu napisać pierwszeństwo obsługi kodu operatorów, aby uzyskać znacznie bardziej czytelny kod.