bonjour jai un probleme avec mon code python :

a = 5
... if a > 0: #si a > que 0
... print("a est plus grand que 0")

si vous pouvez maider svp

A mon avis tu as oublié l'indentation qui est indispensable en Python.

Ton code devrait donner ceci :

>>> a = 5
>>> if a > 0:
...     print("a est plus grand que 0")

Citation : Plug'n'Play 512

A mon avis tu as oublié l'indentation qui est indispensable en Python.

Ton code devrait donner ceci :

>>> a = 5
>>> if a > 0:
...     print("a est plus grand que 0")

Ou sur une seule ligne :

>>> if 42 > 24: print ("toto")
... 
toto
>>>

Tu ne trouves pas que ça n'est pas très raccord avec le PEP8 tout ça ?...

Citation

Tu ne trouves pas que ça n'est pas très raccord avec le PEP8 tout ça ?...

La PEP8 c'est une proposition de l'amélioration de python et j'admet qu'il permet d'aider à mieux construire un programme python.

Mais dans ce cas de figure, je trouve que c'est lisible donc restant en accord avec le but principal de la PEP8.

Oué mais au pire, ça évite le problème de l'indentation.

Mouai enfin il a l'air débutant, donc s'il commence à coder ses conditions et autres boucles sur une seule ligne ça risque de lui poser pas mal de problème, notamment s'il a besoin de changer la valeur d'une variable ou utiliser une boucle dans son if.

Il est toujours déconseillé d'écrire ce genre de truc en une ligne en Python, même dans ce genre de cas très simple.
Le "problème de l'indentation" ne peut de toute façon pas être évité : se dire "on va faire en une ligne comme ça j'aurais pas besoin d'apprendre le sens de l'indentation en Python" est une mauvaise idée. En python, un bloc s'indente.

Le "but principal" de la PEP 8 n'est pas seulement d'avoir des codes lisibles, mais des codes écrits à peu près pareil par tous. Entre maFonction et ma_fonction, la lisibilité est la même, pourtant on conseille ma_fonction pour uniformiser. Et en plus, les blocs unilignes sont toujours moins lisibles.

C'est donc une mauvaise idée de conseiller ça, surtout à un débutant.

Citation : Plug'n'Play 512

Tu ne trouves pas que ça n'est pas très raccord avec le PEP8 tout ça ?...

1°) Beaucoup des lecteurs/participants ne savent pas ce que c'est que le PEP et encore moins le PEP 8 donc merci de placer un lien qui permette de comprendre.
[au passage, pourquoi PEP au masculin ? PEP qui abrège "PEP stands for Python Enhancement Proposal" peut se traduire par "Proposition d'amélioration de Python" donc désormais moi je dirai une PEP à moins que quelqu'un me prouve qu'il faille dire autrement].
Le lien le voici : PEP 8.

2°) Où vois-tu dans la PEP8 un "désaccord" avec ce que j'ai suggéré ? (citation requise)


Ce que j'ai écrit est assez courant même si en regardant dans le code source de Cpython, je n'ai pas vu cette présentation. Par contre, Martelli (grand manitou Python) dans son livre l'emploie couramment.

Citation : Plug'n'Play 512

Mouai enfin il a l'air débutant, donc s'il commence à coder ses conditions et autres boucles sur une seule ligne ça risque de lui poser pas mal de problème, notamment s'il a besoin de changer la valeur d'une variable ou utiliser une boucle dans son if.

Absolument, ma remarque n'était peut-être pas très prudente dans la mesure où le débutant pourrait en être embrouillé, mais bon le tout est de lui expliquer mais c'est vrai que dans un premier temps, on ne prend aucun risque à écrire tout sur au moins deux lignes + indentation, qu'il s'agisse de boucles for, while, d'instruction if, de définition de fonctions ou de classes, etc.

Citation : Maxibolt

Il est toujours déconseillé d'écrire ce genre de truc en une ligne en Python, même dans ce genre de cas très simple.

Hum, je te trouve bien catégorique. Tu te fondes sur quoi pour dire ça avec un tel degré de généralité ?

Citation : Maxibolt

C'est donc une mauvaise idée de conseiller ça, surtout à un débutant.

Ça c'est probablement vrai. Mais il y a débutant et débutant et il faut bien qu'à un moment où à un autre, il sache ce genre de choses, ne serait-ce que parce qu'il va le rencontrer, tôt ou tard.

Citation

2°) Où vois-tu dans la PEP8 un "désaccord" avec ce que j'ai suggéré ? (citation requise)

Citation : PEP 8

- Compound statements (multiple statements on the same line) are
generally discouraged.

Yes:

if foo == 'blah':
do_blah_thing()
do_one()
do_two()
do_three()

Rather not:

if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()

- While sometimes it's okay to put an if/for/while with a small
body on the same line, never do this for multi-clause
statements. Also avoid folding such long lines!

Rather not:

if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()

Definitely not:

if foo == 'blah': do_blah_thing()
else: do_non_blah_thing()

try: something()
finally: cleanup()

do_one(); do_two(); do_three(long, argument,
list, like, this)

if foo == 'blah': one(); two(); three()

Citation

Hum, je te trouve bien catégorique. Tu te fondes sur quoi pour dire ça avec un tel degré de généralité ?

PEP 8, lisibilité, et avis commun de bon nombre de codeurs Python.

Citation

Ça c'est probablement vrai. Mais il y a débutant et débutant et il faut bien qu'à un moment où à un autre, il sache ce genre de choses, ne serait-ce que parce qu'il va le rencontrer, tôt ou tard.

Oui enfin là, il n'est pas capable de comprendre pourquoi son "if" ne marche pas. Je ne sais pas ce qu'il te faut de plus pour voir que c'est vraiment pas le moment d'en rajouter avec des trucs en une ligne.

Il y a en fait deux "infractions" à la PEP 8, la deuxième étant print ("toto") (espace entre la fonction et les parenthèses).

Bien sûr, nous savons déjà que ce non-débat ne mènera à rien, je fais la remarque en passant. D'ailleurs, si on passe autant de temps sur chaque problème posté ici, m'est avis qu'on a pas fini de se prendre le bec.

Citation : Maxibolt

Citation : PEP 8

- Compound statements (multiple statements on the same line) are

Ce que j'ai écrit n'est pas concerné.

Citation : Maxibolt

- While sometimes it's okay to put an if/for/while with a small
body on the same line,

Ben donc, ce n'est pas du tout interdit, la PEP est souple en la matière pas comme ton affirmation catégorique ("toujours", "même").

Citation : Maxibolt

Rather not:

if foo == 'blah': do_blah_thing()

D'ailleurs, le code source de l'implémentation officielle est rempli de choses comme ça.

Citation

Hum, je te trouve bien catégorique. Tu te fondes sur quoi pour dire ça avec un tel degré de généralité ?

PEP 8 : non, elle n'est pas catégorique ("sometimes it's okay")

lisibilité : subjective, on est libre !

avis commun de bon nombre de codeurs Python : toi et iPoulet ? entre Martelli et vous, mon choix est vite fait.

Citation : Maxibolt

Oui enfin là, il n'est pas capable de comprendre pourquoi son "if" ne marche pas.

Je sais ce que je fais. Je ne répondais pas au PO mais à celui qui y répondait et la relation "répondre" n'est pas transitive.

Citation : Maxibolt

Je ne sais pas ce qu'il te faut de plus

Il suffit de ne pas dire des choses fausses :

Citation : Plug'n'Play 512

A mon avis tu as oublié l'indentation qui est indispensable en Python.

L'indentation n'est pas indispensable, ce que la personne ne savait sans doute pas et donc elle a appris quelque chose et donc ma réponse n'a pas été vaine.

Citation : iPoulet

Il y a en fait deux "infractions" à la PEP 8, la deuxième étant print ("toto") (espace entre la fonction et les parenthèses).

Citation : iPoulet

Il y a en fait deux "infractions" à la PEP 8,

Ce n'est pas moi qui ai parlé de respecter la PEP en général, j'ai juste parlé d'une chose bien particulière et après lecture, il s'avère bien que ce que j'ai écrit est tout à fait dans la tolérance de la PEP, c'est écrit noir sur blanc.

Citation : iPoulet

la deuxième étant print ("toto") (espace entre la fonction et les parenthèses).

En réalité, j'ai ajouté des parenthèses car je suis naturellement sous Python 2 et pas Python 3, donc je n'avais pas de raison de soigner de point. Et d'une façon générale, c'est un point de la PEP que je ne respecte pas quand j'écrit du code tout venant, en particulier en console, c'est trop contraignant et ça ralentit la frappe.

D'ailleurs, le code de l'implémentation officielle de Python ne respecte pas lui-même ce point donc je ne vais pas être plus royaliste que le roi.

Citation

Ce que j'ai écrit n'est pas concerné.

Il fallait lire toute la partie, pas juste la première ligne. Partie qui va effectivement plus loin que ton petit code à toi.

Citation

Ben donc, ce n'est pas du tout interdit, la PEP est souple en la matière pas comme ton affirmation catégorique ("toujours", "même").

De une, la PEP n'a jamais rien "interdit", plutôt conseillé. De deux, ce serait bien de citer toutes les phrases, et pas juste les parties qui t'arrangent. En l'occurrence, la PEP déconseille ce que tu as fait. Tu as demandé où était le désaccord dans la PEP avec ce que tu as écrit, tu l'as sous les yeux, il te suffit de les ouvrir. Alors non, la PEP ne dit pas "les unilignes tuent les ours polaires et vous vaudront la décapitation". Mais ça n'a jamais été son but.

Citation

PEP 8 : non, elle n'est pas catégorique ("sometimes it's okay")

lisibilité : subjective, on est libre !

avis commun de bon nombre de codeurs Python : toi et iPoulet ? entre Martelli et vous, mon choix est vite fait.

Ni moi, ni iPoulet (à ma connaissance) n'ont écrit la PEP 8. Mais si tu ne connais comme codeurs Python que moi, iPoulet et Martelli, effectivement, c'est vite fait.

Citation

D'ailleurs, le code source de l'implémentation officielle est rempli de choses comme ça.

olol l'otr il écri des truc déconseiller je voi pas pk moi je ferai un truc bi1

Citation

Je sais ce que je fais. Je ne répondais pas au PO mais à celui qui y répondait et la relation "répondre" n'est pas transitive.

Si tu veux vraiment jouer à ça, tu as répondu au sujet. Le sujet a été posté par le PO, donc tu as répondu au PO. Et de toute façon tu as donné une réponse que le PO est susceptible de lire et d'appliquer (et ne reviens pas faire ta mauvaise foi en disant "oh ben non c'est pas à lui que je parlais il ne le fera pas", tu sais parfaitement que même si dans ton esprit c'était pas lui le destinataire, ça fera exactement le même résultat s'il repasse par ici).

Citation

L'indentation n'est pas indispensable, ce que la personne ne savait sans doute pas et donc elle a appris quelque chose et donc ma réponse n'a pas été vaine.

Plus précisément, l'indentation est indispensable pour écrire correctement en Python. Par contre, il est inutile de savoir écrire sur une ligne, à part pour déchiffrer ce genre de code mal écrit.

Citation

Ce n'est pas moi qui ai parlé de respecter la PEP en général, j'ai juste parlé d'une chose bien particulière et après lecture, il s'avère bien que ce que j'ai écrit est tout à fait dans la tolérance de la PEP, c'est écrit noir sur blanc.

La "tolérance" ? Parce que la PEP 8 est intolérante envers certaines choses ? "Rather not" est aussi écrit noir sur blanc pour un code en tout point semblable au tien, à l'instruction près. Je ne suis pas bilingue, mais je ne pense pas que "rather not" veuille dire "conseillé".

Citation

En réalité, j'ai ajouté des parenthèses car je suis naturellement sous Python 2 et pas Python 3, donc je n'avais pas de raison de soigner de point. Et d'une façon générale, c'est un point de la PEP que je ne respecte pas quand j'écrit du code tout venant, en particulier en console, c'est trop contraignant et ça ralentit la frappe.

Argument complètement incohérent. iPoulet n'a pas reproché les parenthèses, mais l'espace entre print et ces parenthèses. On n'a d'ailleurs besoin de cet espace ni avec Python 2.6, ni avec Python 3.1. Si tu veux écrire en 3.1 (et écrire proprement), tu ne le mets pas, et si tu veux écrire en 2.6, soit tu ne le mets pas (parce que ça marchera aussi), soit tu enlèves les parenthèses pour avoir un truc un peu plus aéré.
Et au fait, je ne vois pas en quoi ne pas taper un espace est contraignant et ralentit la frappe.