Lors du test d'adhésion, nous pouvons utiliser:
x not in yOu bien:
not x in yIl peut y avoir de nombreux contextes possibles pour cette expression en fonction de xet y. Cela peut être pour une vérification de sous-chaîne, une appartenance à une liste, une existence de clé dict, par exemple.
Réponses:
Ils donnent toujours le même résultat.
En fait, not 'ham' in 'spam and eggs'semble être une casse spéciale pour effectuer une seule opération "pas en", plutôt qu'une opération "en", puis annuler le résultat:
>>> 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
J'avais pensé au début qu'ils donnaient toujours le même résultat, mais que notseul était simplement un opérateur de négation logique à faible priorité, qui pouvait être appliqué a in baussi facilement que n'importe quelle autre expression booléenne, alors qu'il not ins'agissait d'un opérateur séparé pour plus de commodité et de clarté .
Le démontage ci-dessus était révélateur! Il semble que bien qu'il s'agisse notévidemment d'un opérateur de négation logique, le formulaire not a in best spécialement casse afin qu'il n'utilise pas réellement l'opérateur général. Cela fait not a in blittéralement la même expression que a not in b, plutôt que simplement une expression qui donne la même valeur.
not x in xsest not (x in xs). Mais le fait qu'il soit implémenté en l'analysant exactement dans le même bytecode x not in xsmontre très clairement qu'ils doivent être toujours identiques, par opposition à des choses comme not x == yvs x != yqui devraient donner le même résultat, mais pas obligées (selon les implémentations de __eq__et __ne__impliqué).
L'opérateur
not inest défini pour avoir la valeur vraie inverse dein.
not inc'est préféré parce que c'est plus évident et qu'ils ont ajouté un cas spécial pour cela.Leur signification est identique, mais le vérificateur de guide de style pycodestyle Python (anciennement appelé pep8) préfère l' not inopérateur de la règle E713 :
E713: le test d'adhésion doit être
not in
Voir aussi "Python if x is not Noneou if not x is None?" pour un choix de style très similaire.
D'autres ont déjà indiqué très clairement que les deux déclarations sont, à un niveau assez bas, équivalentes.
Cependant, je ne pense pas que quiconque ait encore suffisamment insisté pour que, puisque cela vous laisse le choix, vous devriez
Et pas nécessairement aussi lisible que possible pour quiconque , même si c'est bien sûr une bonne chose à viser. Non, assurez-vous que le code est aussi lisible que possible pour vous , car c'est vous qui êtes le plus susceptible de revenir sur ce code plus tard et d'essayer de le lire.
En Python, il n'y a pas de différence. Et il n'y a aucune préférence.
not x in xsdans la documentation.