[x or y] vs [x if x else y]

Version imprimable

22/05/2019, 12h52
flapili

[x or y] vs [x if x else y]

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 :D (mon interlocuteur à été incapable de me donner la moindre source)
22/05/2019, 13h29
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

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:

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

et
_if.py

Code:

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

résultat

Code:

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

22/05/2019, 14h21
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 :roll:) et bon c'est la première fois que j'entends ça quoi :weird:
22/05/2019, 14h35
wiztricks

Citation:

Envoyé par flapili

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

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
22/05/2019, 14h45
flapili

Citation:

Envoyé par wiztricks

Si c'est pas dans le PEP8...

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

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 :aie:
22/05/2019, 15h44
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...:D
22/05/2019, 15h47
wiztricks

Citation:

Envoyé par flapili

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

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
22/05/2019, 17h12
flapili
Citation:

Envoyé par wiztricks

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

collègue est un bien grand mot :roll: j'ai déjà bien essayé de lui demander mais il semble qu'il n'ai aucune source ... je pense juste qu'il essaye de faire passer son avis personnel sur la question comme le saint Graal ...

pour ce qui est de la lisibilité c'est peu être une question d'habitude ?

pour les curieux voici le bout de code:
Code:

1 2 3 4 5 6 7 @commands.command() async def cmd(self, ctx, member: discord.Member = None): member = member or ctx.author . . .
22/05/2019, 17h48
wiztricks
Citation:

Envoyé par flapili

collègue est un bien grand mot :roll: j'ai déjà bien essayé de lui demander mais il semble qu'il n'ai aucune source ... je pense juste qu'il essaye de faire passer son avis personnel sur la question comme le saint Graal ...

S'il n'a pas de source... il est peut être victime d'une légende urbaine. le copain du copain de l'homme qui a vu l'ours.

Citation:

pour ce qui est de la lisibilité c'est peu être une question d'habitude ?

oui... mais avec:
Code:

1 2 3 def f(a, b=None): b = b or a
on exclu silencieusement le cas ou b égale 0.
Plus précis serait:
Code:

1 2 3 def f(a, b=None): b = b if b is not None else a
Et si je devais faire de la revue de code, i.e. comprendre le code écrit par d'autres sans doute que je demanderais à ce qu'on soit plus précis... histoire d'éviter au lecteur de se poser des questions sur "est ce que b peut valoir 0 (ou un machin vide), et dans ce cas, que se passe-t-il?".

- W
22/05/2019, 20h22
Sve@r
Bonjour

En dehors de considérations d'homogénéité que tu peux aussi prendre en compte (c'est généralement plus facile quand tout le monde écrit à peu près pareil), il y a quelques subtiles différences dans les deux écritures.

En effet, dans ton exemple res=x or y qui se traduira dans l'autre syntaxe par res=x if x else y, tu remarqueras alors que dans cette dernière écriture, l'élément "x" est appelé 2 fois. Et perso même si généralement je préfère cette seconde syntaxe, dans ce cas précis ça me gêne (que se passe-t-il si "x" est en fait une super énorme fonction super lourde ?). Et donc dans ce cas précis, j'écrirai la première.

Si maintenant on se place dans un cadre plus général (ex res=condition and x or y que tu traduirais alors par res=x if condition else y) alors je préfère la seconde écriture et de loin. D'une part pour des questions de lisibilité que je trouve plus efficace dans l'écriture étendue... mais surtout parce que les deux écritures ne sont pas équivalentes !!!
En effet, l'instruction res=0 if True else -1 donnera 0 tandis que si tu la traduis par res=True and 0 or -1 ça te donnera -1. Hé oui, c'est séquentiel => le "0" suivant le "and" étant faux, l'instruction continue sur le -1 (on a le même souci en shell Unix avec true && false || true qui vaut "true" alors que son homomogue plus longue à écrire mais plus précise if true; then false else true;fi vaudra "false").

Donc voilà. Plus bien évidemment le souci de "b" valant "0" mentionné par wiztricks qui, dans ton cas précis, reste assez difficile à évaluer.

En espérant t'avoir aidé à y voir plus clair.

PS: mais que cela ne t'empêche pas de demander à l'autre ~~gros con~~ collègue d'où il sort ses assertions ;)
Citation:
Envoyé par flapili

pour les curieux voici le bout de code:

Code:

1 2 3 @commands.command() async def cmd(self, ctx, member: discord.Member = None): member = member or ctx.author
Ben moi, là j'écrirais ça ainsi (attention je donne ici une écriture fournissant exactement le même résultat que la tienne sans me préoccuper du cas "0" ou autre valeur fausse)...
Code:

1 2 3 @commands.command() async def cmd(self, ctx, member: discord.Member = None): if not member: member=ctx.author
... tout simplement parce que ça me gêne que vouloir à tout prix faire le kakou en Python amène alors mon code à recopier "member" dans "member"...:aie:
23/05/2019, 07h50
fred1599

Citation:

Envoyé par 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 :D (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.
23/05/2019, 17h58
BufferBob

salut,

Citation:

Envoyé par flapili

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)
23/05/2019, 20h18
VinsS

Citation:

Envoyé par BufferBob

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

Bonjour VinsS,

Citation:

Envoyé par 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:

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:

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:

1 2 3 4 2 2 2 3 3 3 2 2 2 0 0 0
Quant à dire ce qui est le plus pythonique...

24/05/2019, 17h42
Sve@r

Citation:

Envoyé par tyrtamos

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.

Citation:

Envoyé par tyrtamos

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:

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 ?
24/05/2019, 19h07
tyrtamos

Bonjour Sve@r

Citation:

Envoyé par Sve@r

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 ?

Bien sûr! J'évite soigneusement de laisser à mon code des "libertés" au delà de ce qui est strictement nécessaire. Et si des objets d'un mauvais type arrivent, je préfère traiter l'anomalie parce que je déteste les erreurs silencieuses. J'essaie de coder aussi "solide" que je peux, et ça m'a plutôt bien réussi jusqu'à présent...

Désolé, mais j'ai été élevé en programmation avec le langage Pascal, qui ne pardonnait vraiment rien, et j'en ai encore des séquelles! :D