La syntaxe est simple et permet bcp de liberté, car il y a des fois ou cela sert, même si cela peut-être source d'erreurs. Et en python, ne pas avoir d'opérateur ternaire pour un language qui se veut lisible, quand on parle du non sujet des concours de C illisible, c'est ce que j'appelle un sacré manque. Et un manque total de cohérence pour vous.
Tu mélange simplicité et expressivité. Le fait de ne pas avoir implémenté d'opérateur ternaire rend la syntaxe plus simple (un opérateur en moins, l'unique opérateur 3 paramètres, ça fait moins de particularité etc), mais réduit l'expressivité. La limitation de l'expressivité c'est un objectif de python qui ne veut pas que chaque développeurs du langage fasse à sa façon, mais qu'il n'y ai qu'une seule façon de faire.
On pourrait ajouter les solutions cornecul nécessaires en Python pour pallier à l’absence de variables static, quand on fait du procédural... Pénible. Comme a été pénible de se passer 2 décennies d'un switch/case!
Je suis parfaitement d'accord que c'était un manque, mais ça contribuait à la simplicité de la syntaxe : au point de la rendre aride selon moi.
Non. Mais écrire cela situe tout de suite a qui on a affaire.
Tu viens répondre 13 jours après pour après avoir bien réfléchis te dire que faire des attaques ad hominem c'était une bonne idée ? Tu trouve que c'est normal qu'une discussion au sujet de langages de programmation parte en pugilat ? Faut réduire l'affect python n'est pas une équipe de foot.
Oui, mais c'est comparativement rare et les librairies système n'ont aucune chance d'être concernées.
Et ça n'existe pas dans les bibliothèques standards. Entre les bibliothèques "systèmes" qui couvrent un ensemble différent et pas forcément cohérent entre les OS et une bibliothèque standard "pile incluses" qui est disponible partout où tu as accès au langage. C'est une question de choix, perso je trouve que ça se vaut.
sauf quand on se lie à des trucs non libres
Le fait de devoir tout reconstruire pour dire qu'on a pas de problème d'ABI est un pi-aller. Sans reconstruire tu peut très bien avoir le problème en utilisant des extensions de ton compilateur qu'il soit libre ou non.
Et le print et la division et les changements dans les librairies standards...
C'est les 2 cas les moins parlant. En s'y frottant pour de vrai la gestion des chaînes de caractères est bien plus embêtantes et ne peut pas se gérer automatiquement.
Le problème de python, c'est comme souvent les loupés dans la définition initiale et plus un langage est riche plus on en aura.
Et plus en langage est vieux pour il en aura aussi, mais j'ai l'impression que c'est moins le fait d'avoir fait des choix que de vouloir les corriger qui pose problème. Le commité de normalisation du C a tenté de corriger la gestion des nombre à virgule flottante en C99. L’échec me parait bien plus cuisant.
Pour faire la boucle avec le sujet de l'article: S'il n'y avait pas ces problème omniprésents côté python, on n'aurait pas besoin de venv & co!
La gestion des dépendances et complexe, mais non tu n'a pas fréquemment des projets qui meurt et leurs utilisateurs qui se retrouvent à supporter des millions de milliards de lignes de code ou tenter des ésotérismes. Bien sûr tu pourra trouver des cas, comme ça arrive dans tous les écosystèmes. Mais pas significativement plus ou moins qu'ailleurs.
[^] # Re: Simplicité?
Posté par barmic 🦦 . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.
Tu mélange simplicité et expressivité. Le fait de ne pas avoir implémenté d'opérateur ternaire rend la syntaxe plus simple (un opérateur en moins, l'unique opérateur 3 paramètres, ça fait moins de particularité etc), mais réduit l'expressivité. La limitation de l'expressivité c'est un objectif de python qui ne veut pas que chaque développeurs du langage fasse à sa façon, mais qu'il n'y ai qu'une seule façon de faire.
Je suis parfaitement d'accord que c'était un manque, mais ça contribuait à la simplicité de la syntaxe : au point de la rendre aride selon moi.
Tu viens répondre 13 jours après pour après avoir bien réfléchis te dire que faire des attaques ad hominem c'était une bonne idée ? Tu trouve que c'est normal qu'une discussion au sujet de langages de programmation parte en pugilat ? Faut réduire l'affect python n'est pas une équipe de foot.
Et ça n'existe pas dans les bibliothèques standards. Entre les bibliothèques "systèmes" qui couvrent un ensemble différent et pas forcément cohérent entre les OS et une bibliothèque standard "pile incluses" qui est disponible partout où tu as accès au langage. C'est une question de choix, perso je trouve que ça se vaut.
Le fait de devoir tout reconstruire pour dire qu'on a pas de problème d'ABI est un pi-aller. Sans reconstruire tu peut très bien avoir le problème en utilisant des extensions de ton compilateur qu'il soit libre ou non.
C'est les 2 cas les moins parlant. En s'y frottant pour de vrai la gestion des chaînes de caractères est bien plus embêtantes et ne peut pas se gérer automatiquement.
Et plus en langage est vieux pour il en aura aussi, mais j'ai l'impression que c'est moins le fait d'avoir fait des choix que de vouloir les corriger qui pose problème. Le commité de normalisation du C a tenté de corriger la gestion des nombre à virgule flottante en C99. L’échec me parait bien plus cuisant.
La gestion des dépendances et complexe, mais non tu n'a pas fréquemment des projets qui meurt et leurs utilisateurs qui se retrouvent à supporter des millions de milliards de lignes de code ou tenter des ésotérismes. Bien sûr tu pourra trouver des cas, comme ça arrive dans tous les écosystèmes. Mais pas significativement plus ou moins qu'ailleurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll