Perl / Python / Ruby

Je pense qu'il sous-entend que node propose uniquement le strict minimum tandis que Python est fournit batteries included. En gros il fait plus référence à la taille qu'au niveau, je pense.

Après manifestement QuentinC semble assez peu connaitre Python et ça façon d'écrire du code semble très proche de celle utilisé en JS. Je peux comprendre qu'il sente la syntaxe de Python limité dans ce cas car son manque d'expérience en Python le pousse à reproduire des patterns utilisés en JS qui ne sont du coup pas adapté en Python. On a pas la même vision car ces patterns sont certes utiles et important en JS mais inutile en Python dans 99% des cas car on a d'autres façon de faire. Il faudrait parler d'exemple plus complet pour qu'on puisse montrer que ces limitations (volontaire) de Python ne sont en pratique pas gênante.

Par exemple les fonctions anonyme sont importante en JS car tout est asynchrone basé sur les callbacks. En Python l'expressivité du langage réduit ce besoin. Par exemple, avant les dernières versions de js, il n'y avait pas vraiment de for each en JS pour itérer efficacement sur un objet ou un tableau de nombre. Donc si on ne voulait pas passer par une boucle for "à la C", beaucoup utilisaient des fonctions tels que each de jquery ou lodash. Elles utilisent donc les fonctions anonymes. On a pas se besoin en Python car la boucle for le fait déjà. Et il y a d'autres cas comme ça (with par exemple). Un autre exemple est les coroutines depuis Python 3.4 (et institutionnalisé dans Python 3.5) qui s'imposent comme la façon de faire par défaut de la prog asynchrone là où en JS on va utiliser des callback.

Enfin l'exemple du dico de fonctions donné en exemple plus haut n'est pas un pattern très courant en Python.

Tout ça pour dire que ce qui peut s'apparenter à des limitations du langage sont en réalité lié à la méconnaissance et le manque de pratique du langage. On peut citer plein de choses qu'il est possible d'exprimer en Python que JS ne permet pas mais ça n'apporterai pas grand chose. Ce sont deux langages différents qui ne s'utilisent pas du tout de la même façon.

Enfin l'exemple du dico de fonctions donné en exemple plus haut n'est pas un pattern très courant en Python.

Autant je suis d'accord avec tout le reste de ton post, autant je crois que j'aurais beaucoup de mal à te trouver un programme sur lequel j'ai bossé qui n'incorpore pas ce pattern, quitte à ce qu'il soit déguisé derrière une abstraction ou une autre. Le langage lui-même est un fractal de ce pattern (un package est un dictionnaire de modules qui sont des dictionnaires de fonctions et de classes qui sont des dictionnaires d'attributs et de méthodes).

Par contre on ne remplit que très rarement ces dictionnaires à la main de façon explicite. C'est tellement plus sexy d'utiliser des décorateurs pour ça.

Par contre on ne remplit que très rarement ces dictionnaires à la main de façon explicite. C'est tellement plus sexy d'utiliser des décorateurs pour ça.

C'est plutôt pour ça que je disais ça. D'un certain coté les class sont aussi ce pattern. Mais c'est justement parce que j'ai rarement écrit des suites de dico["clé"] = lambda que je dis que ce n'est pas courant. Pour être précis j'aurais dût dire "sous cette forme" probablement.

Je me méfie parce qu'en JS comme la forme objet.truc est équivalente à objet["truc"], les dev ont tendance à utiliser la premiere forme lorsque le nom de la fonction est connu a l'écriture du code et la deuxième pour accéder à cet élément à la compilation. J'ai l'impression que Quentin essai de reproduire ce genre de chose alors qu'en Python on utiliserai plutôt getattr.

C'est un peu pour ça que je dis qu'il nous faudrait le contexte haut-niveau. Il y a vraiment des façon de coder totalement différentes.

Je me méfie parce qu'en JS comme la forme objet.truc est équivalente à objet["truc"], les dev ont tendance à utiliser la premiere forme lorsque le nom de la fonction est connu a l'écriture du code et la deuxième pour accéder à cet élément à la compilation. J'ai l'impression que Quentin essai de reproduire ce genre de chose alors qu'en Python on utiliserai plutôt getattr.

C'est exactement pour ça que j'ai dit que ça m'avait déjà joué des tours. Spécialement pour les dictionnaires ayant des clés fixes.

Par exemple :

1
2
3
4

def func (**args) :
 print(args.plop) # Ah ben zut alors, je suis obligé d'écrire args['plop']

func(plop=123)

J'avoue, je n'ai jamais utilisé python dans le cadre d'un gros projet.

J'ai bien un projet C++ dans lequel j'embarque python 3.4 pour permettre aux utilisateurs de scripter mon programme avec du python, mais dans ce projet je n'ai pas réellement codé en python moi-même, et donc entres autres j'ignore les petits trucs qui donnent vraiment l'air d'être pythonic. J'aurais bien voulu embarquer JS à la place de python dans mon programme en C++ d'ailleurs ! Mais ça semblait être extrêmement compliqué et d'un niveau totalement hors de ma portée, il faut compiler le machin soi-même avec toutes ses dépendances y compris OpenSSL entres autres et c'est une étape que je juge carrément rédibitoire. Alors que pour embarquer python c'est pas si compliqué, on trouve le .lib et le .h dans la distribution de base de python, il n'y a qu'à copier python34.dll et les fichiers de la lib standard, et la doc est super bien faite; puis c'est parti, on peut démarrer avec un truc très simple. C'est à partir de ce côté-là que je me suis un peu interressé à python en fait. Après avoir quitté lua à cause entres autres de sa non-gestion des chaînes multi-octets. ET dans ce projet, les callback sont une obligation, je les utilise notamment pour appeler du code python à partir de C++ quand un évènement survient dans l'application.