Discussion :

[Pyramidev]

En somme Haskell cache son jeu. La syntaxe par indentation est là pour rassurer ceux qui ne sont pas à l'aise avec les notations fonctionnelles (ce qui est assez paradoxal pour un langage fonctionnel ).

À mon avis, la syntaxe par indentation est là pour ceux qui la trouvent plus lisible.

La syntaxe avec les point-virgules et les accolades n'est vraiment nécessaire que pour deux choses :

• mettre plein de chose sur une seule ligne et
• pouvoir générer plus facilement du code Haskell par programme.

Pour Python c'est moins clair. La notation "(x if x > 100 else x*2)" m'apparaît très illogique avec une valeur au début et une à la fin. Et pas même proche d'une tournure du langage naturel.
Mais elle me suggère une question. Est-ce que les parenthèses utilisées comme délimiteurs d'expressions sont propres à if, ou est-ce que toutes les instructions (ou la plupart) peuvent être considérées comme des fonctions et imbriquées de cette façon ?

Il y a deux cas où on utilise le mot-clef if :

• L'instruction if. Exemple :
  

  Code Python :

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

  1
  2
  3
  4
  5
  6
  if inputStr == '7':
  	print("C'est le nombre de jours de la semaine.")
  elif inputStr == '12':
  	print("C'est le nombre de mois dans l'année.")
  else:
  	print('Je ne sais que dire.')

• Une expression conditionnelle :
  

  Code Python :

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

  x if x > 100 else x*2

N'importe quelle expression peut être entourée par des parenthèses. Par exemple, voici une expression équivalente à la précédente :

Code Python :

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

(x if ((x) > (100)) else (((x*2))))

Un cas d'utilisation des parenthèses autour des expressions est d'avoir des expressions sur plusieurs lignes. Par exemple, dans PEP 8, on peut lire l'exemple :

Code Python :

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

1
2
3
4
5
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Sans ces deux parenthèses, l'interpréteur croirait que la première ligne affecte gross_wages à income.

Il n'y a pas que if qui peut être utilisé dans une expression. Par exemple, voici une expression avec for :

Code Python :

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

[x**2 for x in range(1,11)]

Cette liste vaut [1, 4, 9, 16, 25, 36, 49, 64, 81, 100].

[MiaowZedong]

L'indentation pour la lisibilité est une norme depuis le LISP au moins. Ce n'est pas une obligation mais pour la programmation fonctionnelle un peu poussée, avec des imbrications, il est beaucoup plus simple de se repérer à l'indentation que de compter les parenthèses ou accolades. La norme du LISP (qui reste très influent dans la programmation fonctionnelle) est que la machine lit les parenthèses et le programmeur lit les indentations.

[Pyramidev]

La norme du LISP (qui reste très influent dans la programmation fonctionnelle) est que la machine lit les parenthèses et le programmeur lit les indentations.

En général, oui, sauf dans les moments où on fait de la métaprogrammation (c'est-à-dire quand on écrit du code qui lui-même écrit du code) en définissant des macros. Pendant ces moments, le lecteur lit les parenthèses, car celles-ci affichent de manière concise l'arbre syntaxique qu'il va directement manipuler.

[Christian_B]

Il n'y a pas que if qui peut être utilisé dans une expression. Par exemple, voici une expression avec for

Si je comprends bien dans Python il y a une syntaxe spéciale avec des mots clef comme if ou for (distincte de leur utilisation classique) mais pas pour la plupart des instructions (qui ne sont pas aussi des fonctions).

L'indentation pour la lisibilité est une norme depuis le LISP au moins. Ce n'est pas une obligation mais pour la programmation fonctionnelle un peu poussée, avec des imbrications, il est beaucoup plus simple de se repérer à l'indentation que de compter les parenthèses ou accolades.

Je suis bien d'accord qu'une bonne indentation est essentielle pour la lisibilité (dans tous les langages). Une bonne mise en forme (indentation, alignement correct des parenthèses etc) peut souvent être automatisée.

Mais ce qui me choque, peut-être pour des raisons théoriques, depuis le début, c'est qu'un langage confonde correction syntaxique et mise en forme.
D'autre part, en pratique, il me semble les programmes qui restent corrects si on modifie les espaces et tabulations (assimilés à un séparateur simple) posent moins de faux problèmes, peuvent être édités avec différents outils et réglages et être mis en forme de plusieurs façon au choix.

Pendant ces moments, on est content d'avoir des parenthèses partout qui affichent de manière concise l'arbre syntaxique que l'on va directement manipuler.

Oui et c'est possible (comme je dis ci-dessus) parce qu'on sait que le programme reste correct que l'on adopte une présentation "concise" ou non.
C'est pourquoi un langage dépendant de la présentation comme Python ne favorise pas la méta-programmation, la programmation dirigée par les données et les techniques astucieuses du même genre, comme les macro écrasantes de Lisp.

[dad3zero]

Mais oui bien sûr. Python est un langage multi-paradigmes qui veut pouvoir faire du fonctionnel, mais il n'offre pas le même support et la même optimisation qu'un vrai langage fonctionnel come Haskell (). Il y a de grandes différences.

Tout à fait, la raison n'est donc pas tout à fait juste

Dans quel sens Python est-il fonctionnel ?

Python est un langage multi-paradigmes proposant entre autres l'approche fonctionnelle. Donc naturellement non, Python ne garantit pas certains aspects. L'immuabilité des données de l'approche fonctionnelle par exemple est en elle même en contradiction avec l'approche Objet.

Ouh là, non. Si un jour tu as le temps d'apprendre le Haskell, tu verras que c'est trèèès différent du Python.

Mais je sais Comme dit précédemment, je taquinais sur la formulation.

[dad3zero]

Ou alors, si on veut vraiment le faire tenir sur une ligne :

Code Python :

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

doubleSmallNumber = lambda x: (x if x > 100 else x*2) + 1

Nope, violation PEP8

[dad3zero]

Je cite Pyramidev car il a commencé à répondre à la question sur les parenthèses, mais c'est avant tout pour développer.

Juste pour chipoter :

[*]Une expression conditionnelle :

Code Python :

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

x if x > 100 else x*2

En fait c'est la ternaire.

Donc, les parenthèses en Python sont avant tout des symboles de priorité. Même dans ce cas là :

Un cas d'utilisation des parenthèses autour des expressions est d'avoir des expressions sur plusieurs lignes. Par exemple, dans PEP 8, on peut lire l'exemple :

Code Python :

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

1
2
3
4
5
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Sans ces deux parenthèses, l'interpréteur croirait que la première ligne affecte gross_wages à income.

On pourra écrire

Code Python :

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

1
2
3
4
5
income = gross_wages \
          + taxable_interest \
          + (dividends - qualified_dividends) \
          - ira_deduction \
          - student_loan_interest

La PEP8 préférera la première (les parenthèses)

Si je comprends bien dans Python il y a une syntaxe spéciale avec des mots clef comme if ou for (distincte de leur utilisation classique) mais pas pour la plupart des instructions (qui ne sont pas aussi des fonctions).

Personnellement, je le formulerai dans l'autre sens : en Python, il y a des structures qui utilisent if et for pour simplifier l'écriture et la compréhension. La liste en intension ([transformation for element in collection]) n'est qu'une simplification du for classique.

Mais ce qui me choque, peut-être pour des raisons théoriques, depuis le début, c'est qu'un langage confonde correction syntaxique et mise en forme.
D'autre part, en pratique, il me semble les programmes qui restent corrects si on modifie les espaces et tabulations (assimilés à un séparateur simple) posent moins de faux problèmes, peuvent être édités avec différents outils et réglages et être mis en forme de plusieurs façon au choix.

Je ne suis pas certain de comprendre, mais un erreur d'indentation (un décalage d'alignement) peut être corrigé par des outils automatiques. Le choix d'implémentation est qu'à l'exécution le code doit être définitif.