Discussion :

[flapili]

Bonjour,

Quelqu'un me tient que utiliser x or y n'est pas du tout pythonique et qu'il faudrait utiliser x if x else y.

Je n'ai pas trouvé grand chose là dessus, quel est votre avis sur la question ? Si vous avez vous des sources là dessus je prends volontier (mon interlocuteur à été incapable de me donner la moindre source)

[lg_53]

Pour moi c'est pareil, ca renvoit la même chose.
Après si x et y ne sont pas des booléens, la 2eme syntaxe est plus lisible.
Ceci n'engage que moi, d'autres auront peut etre un avis plus éclairé sur la question

[VinsS]

Salut,

J'aurais tendance à dire le contraire, l'opérateur or me semble atomique (une seule opération dans le processeur).

Par curiosité, j'ai vérifié les bytecodes produit dans les deux cas.

Nous avons
_or.py

Code :

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

1
2
3
 
def ou(x, y):
    return x or y

et
_if.py

Code :

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

1
2
3
 
def si(x, y):
    return x if x else y

résultat

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _or, _if
>>> import dis
>>> dis.dis(_or)
Disassembly of ou:
  2           0 LOAD_FAST                0 (x)
              2 JUMP_IF_TRUE_OR_POP      6
              4 LOAD_FAST                1 (y)
        >>    6 RETURN_VALUE
 
>>> dis.dis(_if)
Disassembly of si:
  2           0 LOAD_FAST                0 (x)
              2 POP_JUMP_IF_FALSE        8
              4 LOAD_FAST                0 (x)
              6 RETURN_VALUE
        >>    8 LOAD_FAST                1 (y)
             10 RETURN_VALUE
 
>>>

and the winner is ....

[flapili]

bon mon interlocuteur me répète en boucle que j'ai qu'a aller voir la PEP8 sans me donner la moindre ligne affirmant ce qu'il avance ...(bien évidement je n'ai rien trouvé dans le PEP8)
d'après lui x or y est déconseillé dans TOUS LES STYLES GUIDES (se sont ces mots ) et bon c'est la première fois que j'entends ça quoi

[wiztricks]

d'après lui x or y est déconseillé dans TOUS LES STYLES GUIDES (se sont ces mots ) et bon c'est la première fois que j'entends ça quoi

Si c'est pas dans le PEP8...
De toutes façons, c'est d'abord une question de "style"... et de fait "non technique".
La technique s'arrête a on obtient le même résultat ou pas, voire c'est plus rapide ou pas, i.e. des trucs "tangibles".

Après on entre dans la culture d'un groupe de développeurs qui préférera une construction à une autre.

Dans la pratique, comment çà se passe? Le responsable des développeurs en a marre de répondre à ces questions qui font perdre du temps. Alors il pond un style guide dans lequel il ferme nombre de discussions - on fait comme c'est écrit dans le style guide et on code plutôt que de discutailler du sexe des anges à la machine à café.
Quelques mois, années/projets plus tard, le "style guide" accompagne les développeurs qui l'appliquent sans se poser de questions.
Si un nouveau arrive et ose poser une question, on lui claquera le bec en lui disant que c'est déconseillé dans tous les "style guide" ou que c'est historique.
Et on lui rappellera qu'il doit appliquer les règles sous peine de voir son code retoqué.

- W

[flapili]

Si c'est pas dans le PEP8...

c'est de l'ironie ou pas ? j'arrive pas à savoir

C'est juste que mon interlocuteur ose me dire que c'est dans les fondements même de python, du même style que pas d'espace avant les ,/:/ect
d'après lui a = x or y se serait comme utiliser this dans une classe

[tyrtamos]

Bonjour,

J'avais fait un petit travail sur le sujet du conditionnel monoligne, il y a un "certain temps": http://python.jpvweb.com/python/mesr...else_monoligne.

En fait, la version avec "if" est apparu avec Python v2.5. Avant, on se débrouillait, et ce qu'on utilisait, genre (condition and x or y) n'était qu'un astuce. Assez bien trouvée cependant!

Ça continue à marcher, mais moi, j'adopte maintenant systématiquement la nouvelle syntaxe (x if condition else y) pour une seule raison: j'attache beaucoup d'importance à la lisibilité de mon code, et je trouve que c'est beaucoup plus facile à lire et à comprendre.

Quant à la PEP8, je la respecte le plus souvent, mais il ne faut pas devenir intégriste pour autant...

[wiztricks]

c'est de l'ironie ou pas ? j'arrive pas à savoir

Si c'est dans tous les guidelines et que c'est pas dans celui là, vous savez déjà que...
Et en tous cas, vous pouvez toujours aller demander à votre collègue où il a trouvé çà dans le PEP8 et de vous montrer les guidelines dont il parle.

- W

[fred1599]

Bonjour,

Quelqu'un me tient que utiliser x or y n'est pas du tout pythonique et qu'il faudrait utiliser x if x else y.

Je n'ai pas trouvé grand chose là dessus, quel est votre avis sur la question ? Si vous avez vous des sources là dessus je prends volontier (mon interlocuteur à été incapable de me donner la moindre source)

Franchement aucun avis sur la question, pythonique est un terme subjectif...

Perso j'ai dans mon taf trouvé plus de x or y que de x if x else y et pourtant je préfère la deuxième expressions car elle exprime en ce qui me concerne plus le besoin. Sans justification autre que c'est plus pythonique, ça ne mérite je pense que très peu d'attention.

Si tu connais les risques liés à cette expression et que tu peux les gérer facilement, alors te pose pas de question, utilise ce que tu comprends et maîtrises le mieux.

[BufferBob]

salut,

Quelqu'un me tient que utiliser x or y n'est pas du tout pythonique et qu'il faudrait utiliser x if x else y

l'opérateur ternaire en Python c'est b if a else c, mais si le propos est de prendre "la première des deux variables qui contient quelque chose" le OU logique suffit, mais il s'agit là d'un cas spécifique/limite et on ne peut évidemment pas généraliser (et la généralisation en a and b or c n'est pas fiable, Sve@r l'a bien expliqué plus haut)

l'opérateur ternaire est résolument "pythonique" en ce sens que la syntaxe ne se trouve à ma connaissance que chez Python (d'habitude c'est plutôt un truc genre (a)?b:c)

concernant la forme a or b c'est du Python tout ce qu'il y a de régulier, mais c'est loin d'être propre à Python, c'est juste de la logique booléenne.

la question derrière le "pythonique" semble donc -dans ce cas précis- être celle d'un code écrit "dans les règles de l'art" VS un code qui marche tout aussi bien, bien que peut-être moins lisible pour certains (à moins d'avoir des millions d'opérations similaires la différence observée dans le bytecode risque d'être complètement négligeable)

[VinsS]

à moins d'avoir des millions d'opérations similaires la différence observée dans le bytecode risque d'être complètement négligeable

Ça c'était pour confirmer que l'opération était plus rationnelle. Sans plus.

Mais il n'empêche qu'il est difficile de comprendre que x ou y est moins lisible que x si x est vrai sinon ben y.

Si quelqu'un peu défendre la meilleure lisibilité de la deuxième syntaxe, je suis tout yeux.

[tyrtamos]

Bonjour VinsS,

Mais il n'empêche qu'il est difficile de comprendre que x ou y est moins lisible que x si x est vrai sinon ben y.

Si quelqu'un peu défendre la meilleure lisibilité de la deuxième syntaxe, je suis tout yeux.

Dans mon message précédent, j'en restais au "if then else" monoligne en général. Mais ici, c'est un cas très particulier dans lequel la condition est en même temps l'une des valeurs. Et dans ce cas, le "x or y" a l'air lisible et l'autre formulation semble alors un peu artificielle.

Il reste que, pour moi, je comprends bien le "or" comme un opérateur booléen qui devrait lier deux variables booléennes vrai/faux (voir table de vérité). Chez Python, comme dans d'autres langages, le fait de dire "0=faux et différent_de_0=vrai" n'est qu'un artifice bien pratique, et ça marche même pour d'autres objets pour lesquels la valeur "vide" est traduite par "faux": str, list, tuple, dict, etc... Mais le résultat de cet opérateur booléen "or" sur x et y devrait être un booléen vrai/faux et non x ou y.

En ce qui me concerne, si je veux échapper à cet artifice, la formulation que je comprendrais le mieux du 1er coup d’œil à la lecture de mon code, même après 6 mois, (et si x est un entier) serait plutôt:

Code :

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

x if x!=0 else y

même si j'ai conscience que ça coûte quelques microsecondes en plus...

En tout cas, les 3 formulations ont l'air de donner les mêmes résultats:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
x, y = 2, 3
print(x or y, x if x else y, x if x!=0 else y)
 
x, y = 0, 3
print(x or y, x if x else y, x if x!=0 else y)
 
x, y = 2, 0
print(x or y, x if x else y, x if x!=0 else y)
 
x, y = 0, 0
print(x or y, x if x else y, x if x!=0 else y)

Ce qui donne:

Code :

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

1
2
3
4
2 2 2
3 3 3
2 2 2
0 0 0

Quant à dire ce qui est le plus pythonique...

[Sve@r]

Chez Python, comme dans d'autres langages, le fait de dire "0=faux et différent_de_0=vrai" n'est qu'un artifice bien pratique, et ça marche même pour d'autres objets pour lesquels la valeur "vide" est traduite par "faux": str, list, tuple, dict, etc... Mais le résultat de cet opérateur booléen "or" sur x et y devrait être un booléen vrai/faux et non x ou y.

Ben justement, c'est bien pratique d'en profiter non ?
J'ai revu quelques uns de mes codes aujourd'hui et justement j'ai constaté que j'use plus souvent que je ne le pensais de cette possibilité res=x or y pour récupérer dans "res" la première valeur non fausse. Mais comme je l'avais dit, dans ce cas précis je trouve cette écriture plus simple en toute chose que d'autres alternatives.

En ce qui me concerne, si je veux échapper à cet artifice, la formulation que je comprendrais le mieux du 1er coup d’œil à la lecture de mon code, même après 6 mois, (et si x est un entier) serait plutôt:

Code :

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

x if x!=0 else y

même si j'ai conscience que ça coûte quelques microsecondes en plus...

Mais si "x" n'est pas entier (ex gros_truc() if gros_truc() != 0 else petit_truc()). Vas-tu coder alors de différentes façons selon la nature de "x" ? Et si "x" évolue ensuite pour passer de entier à "gros_truc()", vas-tu alors revoir tout ton code ?