Discussion :

[PauseKawa]

Bonjour,

Question perte de temps:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not e in l

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if e not in l

?

@+

[josmiley]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not e in l

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not (e in l)

[PauseKawa]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not <bool>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)...

[PsycoPy]

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 python :

Sélectionner tout - Visualiser dans une fenêtre à part

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é...

[Papy Octet]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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+

[afranck64]

Bonjour,

Question perte de temps:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not e in l

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if e not in l

?

@+

le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

not e in l

me parait plus mathématiques , tandis que le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

e not in l

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

[wiztricks]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def f1(z):
    if z not in L:
        pass

génère les opcodes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def f2(z):
    if not z in L:
        pass

on obtient la même chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Papy Octet]

Bonjour wiztricks,

Merci pour cette réponse "rassurante"

[PauseKawa]

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

@+

[PauseKawa]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

              6 COMPARE_OP               7 (not in)

[dividee]

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

[PauseKawa]

Bonjour,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 ).

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.

le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

not e in l

me parait plus mathématiques , tandis que le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

e not in l

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

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 ?

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

@+