if not e in l ou if e not in l ?

Bonjour,

Question perte de temps:

Code:

---

if not e in l

---

ou

Code:

---

if e not in l

---

?

@+

Code:

---

if not e in l

---

me parait plus logique... car on peut l'écrire comme ça:

Code:

---

if not (e in l)

---

C'est bien ce que je pense aussi vis à vis de la comparaison booléenne.

Code:

---

if not <bool>

---

Code:

---

1 2 3 4

>>> l = (1, 2) >>> e = 1 >>> type(e in l) <type 'bool'>

---

Pour ce qui est de if not (e in l)...

Pour l'interpréteur cela ne fait aucune différence mais pour le lecteur humain ça sonne plus mieux bien avec if element not in iterable.

La première forme reste claire et correspond plus à ce qui peut se faire dans d'autres langages. À condition de bien comprendre l'ordre dans lequel Python va traduire l'instruction :

Code:

---

1 2 3 4 5

if (not e) in ls: # erreur d'interprétation humaine possible # ... if not (e in ls): # interprétation humaine correct # ...

---

Ce n'est que mon avis. Mais en même temps je ne sais toujours pas pourquoi 42, alors je vous laisse juger de ma crédulité... :aie:

[QUOTE=PauseKawa;6902021]C'est bien ce que je pense aussi vis à vis de la comparaison booléenne.

Code:

---

1 2 3 4

>>> l = (1, 2) >>> e = 1 >>> type(e in l) <type 'bool'>

---

Bonjour PauseKawa,
Il est normal de recevoir "type bool" à la question en ligne 3 puisque c'est "la comparaison" qui renvoie Vrai ou Faux selon le résultat. Si (1 est bien dans l, alors la condition est vraie).
Un "Type (e)" renvoie un 'str', 'int', ... selon le formatage de la variable et de son contenu. Idem pour 'l'.

A+

Citation:

---

Envoyé par PauseKawa

Bonjour,

Question perte de temps:

Code:

---

if not e in l

---

ou

Code:

---

if e not in l

---

?

@+

---

le

Code:

---

not e in l

---

me parait plus mathématiques :mouarf:, tandis que le

Code:

---

e not in l

---

me semble linguistique, il est parfait pour des littéraires qui se mettent à coder :aie:

Salut,

"not in" est un opérateur en tant que tel.
Qu'on écrive "not z in L" où "z not in L": l’interpréteur générera les mêmes opcodes traduisant "z not in L".

Code:

---

1 2 3

def f1(z): if z not in L: pass

---

génère les opcodes:

Code:

---

1 2 3 4 5 6 7 8

4 0 LOAD_FAST 0 (z) 3 LOAD_GLOBAL 0 (L) 6 COMPARE_OP 7 (not in) 9 POP_JUMP_IF_FALSE 15   5 12 JUMP_FORWARD 0 (to 15) >> 15 LOAD_CONST 0 (None) 18 RETURN_VALUE

---

sous la forme:

Code:

---

1 2 3

def f2(z): if not z in L: pass

---

on obtient la même chose:

Code:

---

1 2 3 4 5 6 7 8

8 0 LOAD_FAST 0 (z) 3 LOAD_GLOBAL 0 (L) 6 COMPARE_OP 7 (not in) 9 POP_JUMP_IF_FALSE 15   9 12 JUMP_FORWARD 0 (to 15) >> 15 LOAD_CONST 0 (None) 18 RETURN_VALUE

---

C'est la même chose pour "not z is L" vs. "z is not L": "is not" est aussi un opcode.

Ceci dit "not in" et "is not" existent dans l'espoir que les codes soient plus lisibles. Et je pense qu'il est plus lisible de... (dans la plupart des cas).
- W

Bonjour wiztricks,

Merci pour cette réponse "rassurante" ;)

Bonjour,

@wiztricks : J'avais hésité un moment avant de dire dans le sujet que le code est le même pour l’interpréteur au vu de dis au cas ou cela empêche une réponse.

@ll : La question ne porte en effet pas sur le code lui même mais la présentation de celui ci. En fait une application d'import this / du pythonesque à la présentation du code.

Pour ma part je pense que la forme if not <condition> et bien plus proche de l'esprit du langage.

Dans l'attente d'autre avis je vais faire mon yoga ;)

@+

Je me demande si Python n'as pas lui même donner la réponse...

Code:

---

6 COMPARE_OP 7 (not in)

---

Pour ma part j'utilise toujours la forme not in parce que:

1. c'est plus lisible
2. je n'arrive jamais à retenir la priorité des opérateurs, et je suis trop fainéant pour vérifier ou pour mettre des parenthèses

Bonjour,

Citation:

---

Envoyé par dividee

c'est plus lisible

---

Il me semble que c'est une grande partie de la réponse, l'interprétation du code par Python n'ayant rien a faire de mes états d’âme et l'opérateur not in étant interprété de la même façon (valable aussi pour la comparaison d'identité is not).
Le code étant le même toute considération de performance n'as lieu d’être ici, si ce n'est le fait de devoir ou pas parcourir la collection au complet, soit utiliser in ou pas.

Une autre considération est de savoir s'il est utile ou pas de construire la collection si celle ci n'existe pas.

Code:

---

1 2 3 4 5 6 7 8

>>> a = 0 >>> b = 1 >>> False in (a, b) True >>> False not in (a, b) False >>> a and b 0

---

(or considération not a and a is not None)
Je pense que cela sera justifié, au final, par Simple is better than complex (on en reviens à la lecture).

Pour moi if not doit être utiliser pour le True/False implicite (if not foo) et not in pour "l'appartenance" (in). Cela reviens a

Citation:

---

Envoyé par dividee

je n'arrive jamais à retenir la priorité des opérateurs, et je suis trop fainéant pour vérifier ou pour mettre des parenthèses

---

C'est explicite pour le lecteur (on a notre import this ;)).

Citation:

---

Envoyé par PauseKawa

Pour ma part je pense que la forme if not <condition> est bien plus proche de l'esprit du langage.

---

Reste donc vrais dans le cadre booléen mais sa lecture n'est pas équivalente à not in qui implique l'appartenance ou pas.

Citation:

---

Envoyé par afranck64

le

Code:

---

not e in l

---

me parait plus mathématiques :mouarf:, tandis que le

Code:

---

e not in l

---

me semble linguistique, il est parfait pour des littéraires qui se mettent à coder :aie:

---

Je pense que c'est une erreur.
Le coding style Python dit que if a est préférable à if a != None et en bon pythons on applique cela à tour de bras sans prendre en compte le contexte / la lisibilité du code (Readability counts).
En fait ce qui nous parait plus 'mathématique' dans ce cas c'est le booléen implicite, on en oubli le contexte.
De plus l'interprétation de code retrouvant l'opérateur not in dans tous les cas autant l'utiliser directement.
Après cela qu'importe si cela ressemble à du shakespeare si c'est compréhensible/le message passe pour le lecteur/Python ?

Citation:

---

Envoyé par PsycoPy

La première forme reste claire et correspond plus à ce qui peut se faire dans d'autres langages. À condition de bien comprendre l'ordre dans lequel Python va traduire l'instruction

---

Il la comprendras tel que vous lui présenterez, l'erreur venant du programmeur.

Code:

---

1 2 3 4 5 6 7

>>> l = (0, 1, 2) >>> not (0 in l) False >>> (not 0) in l True >>> (not 5) in l True

---

La priorité des opérateurs de dividee ne pouvant pas s'appliquer à not in celui ci est préférable.

@+