Python pour la rentrée 2019 — partie 1 ― Popularité

Posté par Oliver (site web personnel) le 04 septembre 2019 à 09:26. Édité par M5oul, Ysabeau 🧶, theojouedubanjo, Benoît Sibaud, Davy Defaud, Nÿco et palm123. Modéré par Nÿco. Licence CC By‑SA.

Étiquettes :

sept.

2019

Pour cette rentrée 2019, faisons le point sur Python : actualité, bonnes pratiques Python, astuces, projets intéressants, témoignages…

Cette première partie présente la popularité de Python, chiffres à l’appui. Mais qu’est ce qui explique qu’un vieux langage de vingt‐cinq ans, lent et dont l’indentation influence la compilation, puisse être aussi populaire ?

Licence

Cette dépêche est publiée sous licence CC0 (sous domaine public dans les pays où cela est possible) pour te permettre de recopier, modifier, réutiliser et republier ce contenu sans t’obliger à citer ses auteurs (sauf que la loi de certains pays comme la France t’oblige quand même à citer les auteurs).

Actualité

Bientôt la PyConFR, du 31 octobre au 3 novembre à Bordeaux, lire la dépêche.

Popularité du langage Python

StackOverflow

En 2017, David Robinson, un data scientist travaillant pour StackOverflow, a publié un article intitulé The Incredible Growth of Python dans lequel, en se basant sur le trafic Web de StackOverflow, il réalise une projection du trafic dans les prochaines années. Pour sa projection, David prend en compte les pays à forts revenus, car ce sont souvent les premiers à adopter les nouvelles technologies.

L’année suivante (2018), le trafic Web relatif aux questions Python représente une part de plus en plus importante.

Trafic StackOverflow concernant les principaux langages de programmation entre 2012 et 2018

Chaque année, StackOverflow réalise un sondage publié sous le nom Developer Survey Results.

Je n’ai pas pris en compte HTML et CSS car ils ne figurent pas dans les anciens sondages.

Le langage le plus utilisé ?

2013	2014	2015	2016	2017	2018	2019
1. SQL	JavaScript	JavaScript	JavaScript	JavaScript	JavaScript	JavaScript
2. JavaScript	SQL	SQL	SQL	SQL	SQL	SQL
3. C#	Java	Java	Java	Java	Java	Python
4. Java	C#	C#	C#	C#	Shell	Java
5. PHP	PHP	PHP	PHP	Python	Python	Shell
6. C++	Python	Python	Python	PHP	C#	C#
7. C	C++	C++	C++	C++	PHP	PHP
8. Python	C	C	AngularJS	C	C++	C++
9. ObjectiveC	ObjectiveC	Node.js	Node.js	TypeScript	C	TypeScript
10. Ruby	Ruby	AngularJS	C	Ruby	TypeScript	C
11. Node.js	Node.js	Ruby	Ruby	Swift	Ruby	Ruby

Et la question, certainement la plus intéressante pour sentir le désir des développeurs, concerne les langages (au sens large) les plus aimés, les plus redoutés et les plus désirés.

Le plus aimé ?

2015	2016	2017	2018	2019
1. Swift	Rust	Rust	Rust	Rust
2. C++11	Swift	Smalltalk	Kotlin	Python
3. Rust	F#	TypeScript	Python	TypeScript
4. Go	Scala	Swift	TypeScript	Kotlin
5. Clojure	Go	Go	Go	WebAsembly
6. Scala	Clojure	Python	Swift	Swift
7. F#	React	Elixir	JavaScript	Clojure
8. Haskell	Haskell	C#	C#	Elixir
9. C#	Python	Scala	F#	Go
10. Python	C#	Clojure	Clojure	C#

D’après les résultats de l’étude StackOverflow, Python est le premier langage de programmation qui est à la fois très utilisé et très aimé. C’est aussi le langage le plus désiré.

Le plus désiré ?

2015	2016	2017	2018	2019
1. Android	Android	Python	Python	Python
2. JavaScript	Node.js	JavaScript	JavaScript	JavaScript
3. Python	AngularJS	Go	Go	Go
4. Node.js	Python	C++	Kotlin	TypeScript
5. AngularJS	JavaScript	Java	TypeScript	Kotlin
6. Java	React	TypeScript	Java	Rust
7. iOS	Swift	C#	C++	C++
8. Arduino/R.Pi	MongoDB	Swift	Swift	WebAssembly
9. Swift	Arduino/R.Pi	Ruby	HTML	Java
10. C#	C++	Rust	CSS	SQL

GitHub

Chaque année, l’Octoverse de GitHub comptabilise, à partir des dépôts privés et publics, le nombre de contributeurs uniques par langage de programmation, dont voici la liste des dix premiers langages :

2014	2015	2016	2017	2018
1. JavaScript	JavaScript	JavaScript	JavaScript	JavaScript
2. Java	Java	Java	Java	Java
3. PHP	Python	Python	Python	Python
4. Python	PHP	PHP	PHP	PHP
5. Ruby	Ruby	C#	C++	C++
6. C++	C++	C++	C#	C#
7. C	C#	Ruby	C	TypeScript
8. C#	C	C	Shell	Shell
9. Shell	Shell	Shell	Ruby	C
10. ObjectiveC	ObjectiveC	ObjectiveC	TypeScript	Ruby

Un autre résultat intéressant pour faire des prévisions est l’augmentation du nombre de contributeurs par langage informatique :

Augmentation	Langage
+ 160 %	Kotlin
+ 120 %	HCL
+ 90 %	TypeScript
+ 70 %	PowerShell
+ 70 %	Rust
+ 60 %	CMake
+ 50 %	Go
+ 50 %	Python
+ 40 %	Groovy

D’après les résultats de l’étude GitHub, Python est à la fois le langage ayant une des communautés d’utilisateurs la plus importante (en troisième position), mais aussi ayant une des plus fortes progressions du nombre de ses contributeurs sur la période 2017-2018 (+ 50 %).

Tiobe

Tiobe a une approche indépendante des données des entreprises, pas besoin d’avoir accès aux métriques réseaux du site StackOverflow ou d’analyser les codes source publics et privés de GitHub. Tout simplement, Tiobe utilise une vingtaine de moteurs de recherche avec +"Python programming", et prend le maximum du nombre de résultats (pour éviter de compter plusieurs fois les mêmes résultats). Les langages pouvant avoir des appellations différentes sont regroupés comme JavaScript, JS et SSJS. Les termes "Python3 programming", "Python-3 programming" et "Python 3 programming" ne sont pas pris en compte.

Indice Tiobe entre 2002 et 2019

Avant 2002, l’indice Tiobe utilisait d’autres méthodes pour comptabiliser la popularité des langages de programmation. Son historique remonte à 1989, il y a trente ans !

Tiobe, décerne aussi le prix de la célébrité au langage ayant la plus forte hausse chaque année. Python est le langage ayant été le plus souvent lauréat du prix de la célébrité : en 2007, 2010 et 2018. Nous pouvons aussi supposer de même dans les années 1990 quand on voit que Python obtient des scores de plus de 20 % pour les années 1999 et 1994.

Pourquoi Python a autant de succès ?

car vieux de 25 ans ?
car interprété et lent ?
car pas conçu pour la performance (ne minimise pas la cache cohérence entre processeurs) ?
car l’indentation a une influence directe sur l’exécution ?
car pas de typage statique à l’exécution ?
car dépourvu de switch/case ?
car les appels à des fonctions inexistantes se fait à l’exécution (et en prod) ?
car sudo pip install --upgrade pip répare tout ? [N. D. M. : c’est ironique…]
car on a le choix entre espaces et tabulations ?
car on a toujours Python 2 ?
car l’exécution parallélisée (multi‐threading) est super top gérée ?
car on a les meilleurs outils de débogage et de profilage ?
car c’est juste pour du prototypage, pas pour la prod ?

Allez, à ton clavier, nous avons hâte de connaître ton avis dans les commentaires. ✍🤔 Et n’oublie pas de nous donner un coup de main pour la seconde partie de cette série de dépêches sur Python. 🤩
→ https://linuxfr.org/news/python-pour-la-rentree-2019-partie-2

Aller plus loin

Appel à conférence pour la PyConFR, du 31 octobre au 3 novembre 2019 à Bordeaux (93 clics)
Python — partie 2 ― Python 2 (38 clics)
Python — partie 3 — Installation de Python et de paquets (20 clics)
Python — partie 4 — Py Pyenv (5 clics)
Python — partie 5 — Nix (et Guix) (5 clics)
Python — partie 6 — Pip et Pipx (8 clics)
Python — partie 7 — Environnements virtuels (7 clics)
Python— partie 8 — Pipenv (6 clics)
Python ― partie 9 ― Formateur de code, analyse statique (5 clics)
Python — partie 10 — Entretiens (8 clics)

# Stats

Posté par barmic 🦦 le 04 septembre 2019 à 12:00. Évalué à 7. Dernière modification le 04 septembre 2019 à 12:01.

Faut surtout prendre des pincettes avec ce genre de stats. On voit d'ailleurs des profiles très différents entre chacune.

Python bénéficie amha d'une hype actuel. Je dis pas ça négativement. C'est une dynamique vertueuse qui fait que plus des gens s'en servent plus il y a de bruit autour du langage et plus il y a d'utilisateurs. Il y a quelques coup de projecteurs initiaux flask/django, numpy/panda/…, l'utilisation pour l'éducation, spark, scikit, jupyter,…

Je ne pense pas qu'il faille chercher absolument des causes internes, ça aurait pu être ruby, go, js ou d'autres. Le langage est un terreau suffisant (même pas forcément parfait) et pas forcément unique (d'autres ferraient aussi bien l'affaire).

Il me semble que python aujourd'hui se place là où Basic était placé/devrait se placer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Stats
  
  Posté par weonbin le 04 septembre 2019 à 12:10. Évalué à 2.
  
  C'est un langage facile a prendre en main et permissif, un peu ce qui a fait la popularite de BASIC il y a 30 ans.
  
  Une partie des defauts evoques dans l'article (perfs, typage dynamique) font qu'utiliser ce langage pour autre chose que des applis de petite taille est handicapant.
  - [^] # Re: Stats
    
    Posté par Olivier le 04 septembre 2019 à 13:18. Évalué à 10.
    
    C'est un langage facile a prendre en main et permissif
    
    Python est facile pour démarrer, mais il y a quand même beaucoup de choses qui ne sont pas si simples. Mais il faut commencer par avoir des usages avancés pour s’en rendre compte.
    
    En revanche, non, Python n’est pas permissif. JavaScript est permissif. Python a un typage dynamique, mais un typage fort. Si vous êtes laxiste, ça va vous péter entre les mains.
    
    Python est surtout un langage extrêmement plaisant à utiliser parce que sa syntaxe est très lisible et globalement bien pensée (quoique imparfaite, mais ce n’est rien en comparaison de beaucoup d’autres langages), et parce qu’il apporte une facilité d’utilisation rarement atteinte, qui permet au programmeur de se concentrer sur ce qu’il veut faire plutôt que sur des problèmes annexes.
    La librairie standard est bien fournie, ce que qui donne clé en main énormément de possibilités. Les types de base sont très bien faits.
  - [^] # Re: Stats
    
    Posté par Philippe F (site web personnel) le 04 septembre 2019 à 13:36. Évalué à 10.
    
    utiliser ce langage pour autre chose que des applis de petite taille est handicapant.
    
    Je note quand même que Dropbox et Instagram gèrent une base de plusieurs millions de lignes de Python. Ils ont pas l'air si handicapés que cela…
    
    Perso, je l'utilise sur des applications de toutes tailles. J'ai parfois dépassé les 30 000 lignes. Le seul frein que j'ai rencontré sur Python sur de grosses applications est l'absence de typage des variables/arguments. Problème qui est résolu depuis 5 années avec MyPy.
    - [^] # Re: Stats
      
      Posté par fabrices le 04 septembre 2019 à 14:20. Évalué à 4.
      
      Ça c'est un peu du fantasme le côté laxiste de Python.
      
      Perso j'ai jamais eu trop à souffrir de bogues vicieux à cause de cela, juste des problèmes de typo qui sont détectés uniquement à l'exécution si on utilise pas un outil comme Pylint. Ça c'est une perte de temps versus un temps de compilation.
      
      Par contre les segfaults en C, les threads et les problèmes de mémoire en C / Java on connaît …
      
      D'ailleurs la gestion de la mémoire posent parfois des soucies, pour la même raison que Java : le Garbage collector ne fait pas des miracles.
      
      Pour des attributs privés, la convention « object._attribut » fait une partie du boulot, de même qu'elle est recommandé en C++ là où peut faire un « #define private public » ou pire avec les pointeurs …
      - [^] # Re: Stats
        
        Posté par Blackknight (site web personnel, Mastodon) le 05 septembre 2019 à 09:33. Évalué à 3.
        
        Par contre les segfaults en C, les threads et les problèmes de mémoire en C / Java on connaît …
        
        Déjà comparé C et Python, c'est un peu limite, le C reste, à mon avis, un langage de plus bas niveau que le Python.
        Ensuite, la programmation des threads en Python a exactement les mêmes problèmes que pour tous les langages faisant de la concurrence bas niveau à savoir gérer correctement les verrous et les synchros.
        
        Les segfaults sont un peu le prix à payer pour optimiser la mémoire. D'ailleurs, au passage, tu en as beaucoup des programmes qui tous les jours te font un segfault ?
        
        Pour des attributs privés, la convention « object._attribut » fait une partie du boulot
        
        Le problème, c'est que ce n'est qu'une convention et donc quand on tombe sur du code de débutant, il y a un risque non négligeable que cela ne soit pas respecté.
        
        de même qu'elle est recommandé en C++
        
        Alors, par exemple, la recommandation chez Google, c'est un underscore à la fin, pas au début.
        
        là où peut faire un « #define private public » ou pire avec les pointeurs …
        
        Alors qu'on ne peut absolument pas faire des trucs horrible au runtime en Python comme ajouter à la volée des méthodes, des variables…
        D'ailleurs, rien n'empêche de passer un préprocesseur comme M4 sur du code Python et donc de faire dans le code Python tout ce que l'on peut faire en C/C++.
        Après, on peut définir une convention dans le projet C++ qui interdit l'usage d'un #define sur un mot-clé du langage… Ah merde, c'est qu'une convention.
        
        Au final, tout est question de point de vue.
        
        [^] # Re: Stats
        
        Posté par xryl669 le 05 septembre 2019 à 10:03. Évalué à 1.
        
        C'est quand même vachement simple de détecter ce genre de cas en C++.
        
        class A { private: A() { throw new you_are_a_donkey_exception(); } }; // Si ça, ça compile, c'est qu'il y a un soucis dans tes macros A a;
        
        [^] # Re: Stats
        
        Posté par Samuel Thibault (site web personnel) le 06 septembre 2019 à 10:58. Évalué à 5.
        
        la programmation des threads en Python a exactement les mêmes problèmes que pour tous les langages faisant de la concurrence bas niveau à savoir gérer correctement les verrous et les synchros.
        
        Pas seulement. Comme presque tous les autres langages utilisant un garbage collector, python n'est pas réellement parallèle, il y a un giant interpreter lock. Du coup on ne peut pas profiter d'un multi-cœur avec seulement des threads en Python, tu es obligé de lancer plusieurs interpréteurs.
        
        [^] # Re: Stats
        
        Posté par lolop (site web personnel) le 06 septembre 2019 à 13:03. Évalué à 4.
        
        Le GIL assure que l'interpréteur ne va pas planter violemment à cause de d'accès concurrents malencontreux dans les couches C qui manipulent directement les structures en mémoire.
        
        C'est sûr que c'est un frein à l'utilisation optimale des ressources (surtout pour ce qui est calcul), mais il permet déjà de faire des choses.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Stats
        
        Posté par GuieA_7 (site web personnel) le 07 septembre 2019 à 23:12. Évalué à 3.
        
        Chose amusante, Jython (implémentation de Python en environnement Java) permet le vrai parallélisme (même si évidemment il y a un "stop the world" lors du travail du GC) ; après comme ce n'est pas compatible avec les modules écrits en C pour l'implémentation la plus utilisée (CPython), je ne pense pas que grand monde s'en serve.
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 07 septembre 2019 à 23:41. Évalué à 2.
        
        même si évidemment il y a un "stop the world" lors du travail du GC
        
        Uniquement certaines phases du GC dans certaines conditions. Juste pour bien dire que ce n'est pas à chaque exécution du GC que le monde s'arrête loin de là. Un programme peut s'exécuter éternellement sur la jvm sans stop the world, bien sûr ça demande d'avoir un profile d'usage mémoire très particulier.
        
        je ne pense pas que grand monde s'en serve.
        
        Jython, jruby,… sont de très mauvaises idées. Ce que tu gagne en parallélisme potentiel tu le perds en coup à l'exécution. Réimplémenter le typage dynamique sur la jvm était très coûteux avant l'apparition d'invokeDynamic de java8. Jython n'a pas bougée de 2017, il n'a pas d'implémentation de python 3 (mais elle utilise invokeDynamic). Mais en vérifiant je vous que jruby est toujours maintenu. Il est même à jour par rapport à l'implémentation de référence. J'en vois pas l'intérêt. Groovy est bien plus intéressant pour ce segment.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Stats
        
        Posté par claudex le 12 septembre 2019 à 16:39. Évalué à 3.
        
        Jython, jruby,… sont de très mauvaises idées.
        
        Pas sûr que ce soit de mauvaise idées (sauf si tu vise uniquement les performances). Ça permet de s'interfacer facilement avec du code Java (legacy, pour faire des plugins pour une appli Java…).
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 12 septembre 2019 à 21:52. Évalué à 1. Dernière modification le 12 septembre 2019 à 21:53.
        
        Si java est ton legacy utiliser jython n'a pas de sens. Tu va garder une dépendance vers la jvm qui te sera encore plus difficile à enlever.
        
        Pour faire des plugins, tu as groovy, kotlin, ceylon, scala, closure,… Qui sont bien plus propres dans leur mise en place. Ou js qui fait parti de la bibliothèque standard de java.
        
        Oui, mais si tu veux utiliser un plugin avec une bibliothèque que tu ne trouve qu'en python ?
        
        Eh bien il fait vérifier que cette bibliothèque soit compatible et espérer qu'elle le reste. Bref tu ajoute de la fragilité (on parle d'un code qui sera à peu près compatible avec python et qui sera coincé en python 2.7), là où tu pourrais simplement faire communiquer une application python avec une application java.
        
        J'imagine bien qu'on peut trouver des cas où c'est pas si mal d'utiliser jython, mais dans l'énorme majorité des cas c'est une mauvaise idée, voir une très mauvaise idée (coucou logstash).
        
        Jython est naît à une époque où on pensait que la jvm allait tout déchirer. Ça n'est pas vraiment le cas. On a fait bien mieux maintenant pour les même usages (meilleure intégration à java comme plate-forme) et bien les populaires (il y a bien plus de monde qui utilise groovy avec du java que jython).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Stats
        
        Posté par claudex le 12 septembre 2019 à 22:11. Évalué à 2.
        
        Pour faire des plugins, tu as groovy, kotlin, ceylon, scala, closure,… Qui sont bien plus propres dans leur mise en place.
        
        Tout des trucs très ressemblant à java ou pas super sexy. Bref, si tu veux ouvrir ton monde des plugins à des développeurs externes, je ne suis pas sûr que jython soit un mauvais choix.
        
        Eh bien il fait vérifier que cette bibliothèque soit compatible et espérer qu'elle le reste. Bref tu ajoute de la fragilité (on parle d'un code qui sera à peu près compatible avec python et qui sera coincé en python 2.7), là où tu pourrais simplement faire communiquer une application python avec une application java.
        
        Désolé, je n'étais pas clair dans mon commentaire, je parlais d'un point de vue hypothétique où jython était encore développé. Et que donc, ça avait du sens de développer jython.
        
        De la même manière qu'Ironpython avait du sens (d'ailleurs, je me demande si Microsoft ne regrette pas de l'avoir abandonné un peu trop tôt).
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 12 septembre 2019 à 23:47. Évalué à 1.
        
        Tout des trucs très ressemblant à java ou pas super sexy.
        
        C'est difficile de contre argumenter face à ce genre de subjectivité, mais groovy est très largement utilisé. Je pense même que avec ou sans jvm, je connais plus de logiciels qui embarquent groovy que python (au sens embedded). En fait à part via jython je n'ai mais vu un logiciel embarquer python. Il me semble que c'est plus souvent l'inverse on s'intègre à python plutôt qu'on intègre python à son code.
        
        Désolé, je n'étais pas clair dans mon commentaire, je parlais d'un point de vue hypothétique où jython était encore développé. Et que donc, ça avait du sens de développer jython.
        
        Sauf qu'intrinsèquement jython ne peut pas être python. C'est une implementation du langage au dessus de la jvm, mais elle case la compatibilité avec l'écosystème de python et c'est l'écosystème de python qui le rend intéressant.
        
        De la même manière qu'Ironpython avait du sens (d'ailleurs, je me demande si Microsoft ne regrette pas de l'avoir abandonné un peu trop tôt).
        
        Même pypy a dû mal à suivre: il est en retard d'une version, il n'est pas tout à fait compatible,…
        
        Avoir pleins d'implémentations de python ce serait cool (pour la beauté du geste), mais faut se rendre à l'évidence : python aujourd'hui c'est cpython et rien d'autre. Cette force qui est louée dans les autres commentaires d'utiliser massivement des bibliothèques en C "hyper" optimisées empêche de facto toute autre implémentation d'être pérenne (je pense que c'est aussi pour ça qu'on embarque pas python, mais qu'on se laisse embarquer par lui, ce n'est pizzas forcément un mal. C'est Julien Danjou qui disait qu'il vaut mieux entendre qu'embarquer).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Stats
        
        Posté par GuieA_7 (site web personnel) le 13 septembre 2019 à 22:58. Évalué à 1.
        
        À moins que je n'ai pas compris ce que tu appelles "embarquer", tu es es passé à côté de pleins de logiciels (typiquement écrits en C/C++) et qui embarquent Python. On pensera par exemple à Gimp et à Blender.
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 14 septembre 2019 à 12:24. Évalué à 1.
        
        Après vérification, il me semble que gimp n'embarque pas d'interpréteur python. Les extensions sont des processus lancés à côté de gimp sur le python installé sur le système.
        
        Par embarqué, j'entends ce qui est fait avec jython ou lua. Ce sont des bibliothèques que tu charge et à qui tu demande d'exécuter du code d'un autre langage. Pour js, tu peux soit lancer node, soit utiliser v8. Cette dernière façon c'est ça qu'on appelle embedded.
        
        Je ne suis pas qu'embarquer est mieux. Pas du tout, je suis que quand embarquer un langage oblige à le travestir, ce n'est pas une bonne idée amha. L'exemple de gimp montre que ça n'est pas un frein à l'utilisation en tant que plugin.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 14 septembre 2019 à 12:28. Évalué à 1.
        
        Cette page le décrit clairement. Ils se sont intégré à python plutôt que l'inverse. Les plugins gimp en python, c'est python qui execute du code gimp et pizzas gimp qui execute du code python.
        
        https://www.gimp.org/docs/python/
        
        Ça paraît subtile, mais ça ne l'est pas du tout.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Stats
        
        Posté par GuieA_7 (site web personnel) le 16 septembre 2019 à 17:45. Évalué à 1.
        
        Ok merci d'avoir précisé ta pensée et d'avoir regardé pour Gimp.
        Pour Blender en revanche je pense que c'est bien embarqué comme tu le décris.
        
        [^] # Re: Stats
        
        Posté par barmic 🦦 le 17 septembre 2019 à 09:09. Évalué à 2.
        
        Effectivement, j'étais pas allé vérifier pour blender que je n'ai jamais utilisé, mais leur page de documentation semble bien dire ça : Python API Overview.
        
        Ils parlent bien d'embarquement « Blender embeds a Python interpreter which is started with Blender and stays active » et on ne lancent pas les scripts python blender avec l'interpréteur standard, mais avec blender blender --python /home/me/my_script.py.
        
        C'est effectivement un exemple de python embarqué :)
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: Stats
        
        Posté par flan (site web personnel) le 06 septembre 2019 à 20:55. Évalué à 4.
        
        Personnellement, j'utilise un IDE utile (PyCharm, en l'occurrence). Autrement dit, il me détecte à l'écriture à peu près toutes les erreurs qui seraient détectées à l'écriture également avec du C ou tout autre langage typé. Au besoin, si l'inférence de type ne suffit pas, j'aide un peu l'IDE avec des annotations (notamment pour les rares cas où il ne peut pas deviner l'info).
        Si j'ai une erreur de type à l'exécution, c'est qu'il y a un souci (pas assez d'annotation), mais c'est vraiment rare.
        
        Alors, certes, on peut faire des choses « sales » à l'exécution (bien pire qu'ajouter des méthodes ou des classes :D), mais c'est clairement déconseillé. Cela dit, l'auteur de Python a toujours considéré que c'était un langage pour adultes : si tu veux faire des choses de ce genre, tu peux, mais tu en assumes les conséquences.
# Utilisation de Python par un profane

Posté par Claude SIMON (site web personnel) le 04 septembre 2019 à 12:25. Évalué à 10.

J'ai eu, à l'occasion d'un projet, à programmer en différents langages (Java, Node.js, Perl, PHP, Python et Ruby), dont aucun ne m'était familier, la même bibliothèque faisant appel à des fonctionnalités assez poussées (réseau bas niveau, multi-tâche, gestion d'accès concurrents…), et c'est avec Python que je me suis le plus… amusé. En outre, pour l'implémentation de certains algorithmes, j'ai souvent écrit du code au feeling, trop paresseux que j'étais pour consulter la documentation, et c'est en encore avec Python que le code a le plus souvent fonctionné du premier coup, ou seulement après quelques modifications mineures. Ceci dit, les différences entre les versions 2 et 3, surtout concernant les fonctions réseau bas niveau, sont assez irritantes, mais il est assez facile d'écrire une surcouche qui permette de faire du réseau sans avoir à se préoccuper de la version utilisée de Python (version 2, version 3, surcouche).

Il y a quand même une singularité, que je qualifierais de maladresse, qui a du mal à passer. Par exemple, {1,2} est un set contenant deux nombres (notez les {} comme délimiteurs) et (3,4) un tuple contenant deux nombres (notez les () comme délimiteurs). Jusqu'à là, tout va bien. Par contre, bien que {5} est bien un set contenant un nombre, (6) n'est pas un tuple contenant un nombre, mais le nombre lui-même. Pour avoir un tuple contenant un seul nombre, il faut écrire (7,). Vu l'usage qui est généralement fait des parenthèses, ça peut se comprendre, mais ça reste assez déroutant. À noter que 8,9 (sans les parenthèses) est aussi un tuple contenant deux nombres.

Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.

Concernant l'apprentissage de la programmation, c'est Python qui semble être le plus utilisé. C'est encore lui qui est le langage de prédilection lorsque qu'il s'agit de manipuler les ports GPIO d'un Raspberry Pi. C'est donc vers ce langage que je me suis tourné pour un projet d'outil pédagogique (journal dédié) destiné à être utilisé dans le cadre de cours de programmation. Le fait de facilement avoir accès aux mécanismes internes de Python facilite l'écriture d'exercices pour ce genre de cours (ou du moins l'idée que je me fais d'exercices de ce genre). Alors, ce projet n'existe qu'en Python (pour le moment), donc je ne peux le comparer avec d'autres langages de ce point de vue, mais je ne vois pas trop comment faire mieux que Python. J'ai vraiment facilement et relativement élégamment pu résoudre les problématiques liés à ce genre de projets (vais peut-être faire un journal, voire une dépêche, sur le sujet un de ces jours…). Par contre, je me garderais bien de me prononcer sur la pertinence de l'utilisation de Python pour l'apprentissage de la programmation, n'ayant pas assez de recul.

Ne prenez pas ce commentaire pour plus qu'il n'est : un ressenti, donc totalement subjectif. Sachant, en outre, que, malgré toutes les qualités de Python, et des autres langages que j'ai pu essayer, le C++ reste mon langage de prédilection…

Pour nous émanciper des géants du numérique : Zelbinium !
- [^] # Re: Utilisation de Python par un profane
  
  Posté par lolop (site web personnel) le 04 septembre 2019 à 13:14. Évalué à 8.
  
  Concernant Python 2 et Python 3, à part pour de la maintenance de code ancien conséquent, ou encore la dépendance envers une librairie qui ne tournerait que sous Python 2, celui-ci est à éviter.
  
  Pour tout nouveau projet, ou encore pour de l'enseignement : Python 3.
  
  Et pour le code compatible entre Python 2 et Python 3, si c'était utile il y quelques années car la transition était en cours, c'est maintenant globalement une perte de temps.
  
  Pour rappel, Python 3 est sorti en 2008, ça commence à faire quelques temps, et Python 2 (2.7) ne sera plus maintenu à partir de 2020.
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Utilisation de Python par un profane
    
    Posté par Oliver (site web personnel) le 04 septembre 2019 à 13:31. Évalué à 4.
    
    Justement la partie 2 de cette série de dépêche va un peu parler de Python 2.
    N'hésitez pas à compléter/corriger la partie 2 avant sa publication:
    https://linuxfr.org/news/python-pour-la-rentree-2019-partie-2/
    Merci 💚 🐍
    
    Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
    - [^] # Re: Utilisation de Python par un profane
      
      Posté par lolop (site web personnel) le 04 septembre 2019 à 15:45. Évalué à 1.
      
      (pas vu de zone de discussion sur la page de rédaction)
      
      Avant que je n'y touches…
      
      Ne serait-il pas mieux de présenter d'abord les bonnes façons de faire, et ensuite seulement les autres façons que l'on peut trouver indiquées sur le Net (et pourquoi elles sont moins bonnes) ?
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Utilisation de Python par un profane
        
        Posté par Oliver (site web personnel) le 04 septembre 2019 à 16:52. Évalué à 3. Dernière modification le 04 septembre 2019 à 16:53.
        
        (pas vu de zone de discussion sur la page de rédaction)
        
        La zone de discussion ne se voit pas sur un petit écran (ou une fenêtre pas très large). Si tu peux, met la fenêtre en plein écran, tu verras la zone de discussion à droite. Avec un smartphone, peut-être en mode paysage… Au pire, tu scrolles tout en bas de la page, et tu auras la zone de discussion.
        
        Ne serait-il pas mieux de présenter d'abord les bonnes façons de faire, et ensuite seulement les autres façons que l'on peut trouver indiquées sur le Net (et pourquoi elles sont moins bonnes) ?
        
        Oui c'est une très bonne idée. Souhaites-tu t'occuper de modifier l'ordre actuel des sections ? Je t'en prie, considère que c'est aussi ta dépêche. On peut déplacer certains chapitres dans une autre dépêche à paraître ultérieurement si tu penses que c'est pertinent. 😃
        
        Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
- [^] # Re: Utilisation de Python par un profane
  
  Posté par Olivier le 04 septembre 2019 à 14:11. Évalué à 6.
  
  Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.
  
  Enum existe depuis plus de 5 ans.
- [^] # Re: Utilisation de Python par un profane
  
  Posté par lolop (site web personnel) le 04 septembre 2019 à 19:51. Évalué à 5. Dernière modification le 04 septembre 2019 à 19:51.
  Un des trucs qui m'embête le plus pour mes étudiants, c'est le transtypage automatique vers booléen. Ça peut être un très gros piège.
  
  Par exemple certains me traduisent le français « si x vaut 1 ou 2 ou 3 » littéralement en :
```
if x==1 or 2 or 3:
```
  Au lieu de
```
if x==1 or x==2 or x==3:
```
  Ou encore (pour les plus avancés) en une expression in vs un conteneur.
  
  En tant que développeur j'apprécie beaucoup ce raccourci de transtypage, mais pour l'enseignement à des non informaticiens je le regrette — mais probable qu'une obligation de valeurs bool pour les opérateurs and, or et not en Python 3 aurait été un changement trop radical, du même ordre que le / rendu flottant par défaut.
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Utilisation de Python par un profane
    
    Posté par Christophe B. (site web personnel) le 05 septembre 2019 à 09:09. Évalué à 2. Dernière modification le 05 septembre 2019 à 09:12.
    Avec
```
    if x==1 or 2 or 3:
```
    La syntaxe est ambigüe, c'est à éviter absolument , beaucoup de bug proviennent d'une syntaxe ambigue
    
    Avec x=1 y=2 z=3 quelle est la valeur de : x * 3 - y + z - 4 ?
    
    python l'interprète de gauche à droite et le résultat est 0
    
    mais en fait tu voulais exprimer (x * 3) - ((y + z) - 4)
    et dans ce cas le résultat est 2
    
    Cependant c'est exactement le genre de piège qu'il faut étudier avec tes élèves et leur apprendre à écrire du code lisible sans ambigüité.
    
    Il y a longtemps j'ai fait un test de montrer à des devs du code python, sans connaître le langage la majorité comprenait ce que faisait le script.
    
    Ce n'est pas le cas avec tout les langages.
    
    Et s'il te plaît si tes étudiants doivent devenir des professionnels de l'informatique dis leur de se poser 2 questions quand ils codent : Fréquence et volume
    
    Fréquence : quelle est la fréquence d'utilisation du script ? 1 fois par an / 1 fois par minute etc …
    Volume : quelle est le volume de données à traiter ? 1 Ko / 1 Mo / 1 Go …
    
    Cela évitera beaucoup de problèmes, cris, larmes etc …
    
    je suis effaré de voir certains Chef de projets/ Consultants / devs etc … ne JAMAIS se poser ce genre de question.
    
    Enfin si je puis me permettre de te donner un conseil sur ta méthode d'enseignement alors que je n'ai aucune légitimité.
    - [^] # Re: Utilisation de Python par un profane
      
      Posté par Bernez le 05 septembre 2019 à 09:41. Évalué à 6.
      
      Avec x=1 y=2 z=3 quelle est la valeur de : x * 3 - y + z - 4 ?
      
      python l'interprète de gauche à droite et le résultat est 0
      
      mais en fait tu voulais exprimer (x * 3) - ((y + z) - 4)
      
      Python se contente de suivre les règles de priorités normales des mathématiques. Je ne comprends pas comment tu en es venu à vouloir l'interpréter autrement.
      - [^] # Re: Utilisation de Python par un profane
        
        Posté par Christophe B. (site web personnel) le 05 septembre 2019 à 12:18. Évalué à -1.
        
        Honnetement c'est parce que je n'arrive pas à retenir les règles de priorités normales de mathématique
        trop compliqué pour moi, et je dois pas être le seul …
        
        Aussi j'utilise systèmatiquement des parentheses pour éviter toute ambiguité.
        
        Le code doit être lisible par tout le monde … par forcément que par les matheux ou les pythonistas pur jus qui sont moins nombreux que les autres :) les bipédes de catégorie moyennes comme moi.
        
        L'ambiguité qui est génératrice de bug, pas les règles de priorités normales de mathématique.
        
        parfois la communication passe par le plus petit dénominateur commun …
        
        [^] # Re: Utilisation de Python par un profane
        
        Posté par barmic 🦦 le 05 septembre 2019 à 13:07. Évalué à 3.
        
        Le code doit être lisible par tout le monde … par forcément que par les matheux ou les pythonistas pur jus qui sont moins nombreux que les autres :) les bipédes de catégorie moyennes comme moi.
        
        Hum… « Le code doit être lisible par moi. » Tu pense être un étalon particulièrement représentatif ?
        
        Le langage des parenthèse lui-même peut être source d'erreur en alourdissant une expression il peut la rendre moins lisible. Pour un exemple trop trivial pour être représentatif, je lis plus vite ax+b que (a*x)+b.
        
        Pour moi le code n'a pas à être lisible par tout le monde, il doit être lisible par ceux qui vont le lire. Si les gens qui participent à un logiciel ont une culture ou un bagage commun (ou qui est considéré comme une hypothèse de base pour travailler), je ne vois pas de raison de ne pas s'appuyer dessus.
        
        Et je n'ai pas de doute que tu le fait toi-même. Tu as un domaine que tu maîtrise bien. Il y a forcément des choses que tu trouve évidentes dans ce domaine et la méthode pour ne serais-ce que voir que tu as quelque chose de plus ou moins implicite dans ton code n'est pas simple.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Utilisation de Python par un profane
        
        Posté par flagos le 05 septembre 2019 à 15:01. Évalué à 4.
        
        Honnetement c'est parce que je n'arrive pas à retenir les règles de priorités normales de mathématique
        trop compliqué pour moi, et je dois pas être le seul …
        
        Faut quand même pas pousser mémé. Les priorités sont au programme de maths de 5eme. Pas besoin d’être ingénieur a la NASA ou d'avoir eu un prix Nobel pour les maitriser.
        
        Les règles de priorité font parti du dénominateur commun comme la lecture des quelques mots anglais que l'on trouve de base dans le langage (in/or/and/for/while)
        
        [^] # Re: Utilisation de Python par un profane
        
        Posté par Tit le 05 septembre 2019 à 15:46. Évalué à 3.
        
        Le code doit être lisible par tout le monde … par forcément que par les matheux ou les pythonistas pur jus qui sont moins nombreux que les autres :)
        
        tu parles de pythonistes mais je suppose que c'est pareil dans (presque) tous les langages, non ? par exemple en c++ tu pense que ton x * 3 - y + z - 4 n'aura pas le même résultat ? (je fais pas de c++)
        de même matheux ça me semble un peu fort, je suppose que la très très grande majorité des élèves de collège te donneront la bonne réponse.
    - [^] # Re: Utilisation de Python par un profane
      
      Posté par lolop (site web personnel) le 05 septembre 2019 à 11:23. Évalué à 1.
      
      Mes étudiants ne se destinent pas à une carrière d'informaticien («mais pour l'enseignement à des non informaticiens»), cette matière est secondaire pour eux… je liste certains pièges, en montre d'autres en TP/TD, mais les heures dispos ne permettent pas d'approfondir (et ils n'en ont pour la plupart pas grand chose à faire).
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Utilisation de Python par un profane
        
        Posté par Christophe B. (site web personnel) le 05 septembre 2019 à 12:19. Évalué à 1. Dernière modification le 05 septembre 2019 à 12:21.
        
        cette matière est secondaire pour eux
        
        Pour l'éducation nationale aussi on dirait … même si le choix du langage python m'a surpris agréablement
        
        d'ou vient ce choix d'ailleurs ?
    - [^] # Re: Utilisation de Python par un profane
      
      Posté par Tit le 05 septembre 2019 à 15:54. Évalué à 1.
      
      Avec
      
      if x==1 or 2 or 3:
      
      La syntaxe est ambigüe
      
      Je ne comprends pas ton argument : en quoi c'est ambigu ?
      s'ils avaient écrit le condition correcte
      if x==1 or x==2 or x==3tu aurais toujours trouvé cela ambigu ?
      - [^] # Re: Utilisation de Python par un profane
        
        Posté par barmic 🦦 le 05 septembre 2019 à 16:01. Évalué à 1.
        
        Je ne comprends pas ton argument : en quoi c'est ambigu ?
        
        Le transtypage des entiers en booléen, je présume.
        
        L'expression x==1 or 2 or 3 est valide en python et donne un résultat contre intuitif pour ses élèves (mais très cohérent avec beaucoup d'autres langages).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Utilisation de Python par un profane
        
        Posté par Tit le 06 septembre 2019 à 11:03. Évalué à 0. Dernière modification le 06 septembre 2019 à 11:03.
        
        Oui mais vu l’exemple qu'il donne ensuite, j’imagine que ce n'est pas ce qu'il veut dire (surtout qu'il répond à lolop qui a justement parlé de ce problème du transtypage automatique), j'ai l'impression (sans être sûr c'est pour ça que je pose la question) qu'il dit qu'il faut mettre des parenthèses pour éviter l'ambiguité… j'en déduis donc que pour traduire "si x est égal à un ou deux ou trois", il aurait fallu écrire if (x==(1 or 2 or 3)) ;-)
        
        [^] # Re: Utilisation de Python par un profane
        
        Posté par lolop (site web personnel) le 06 septembre 2019 à 13:04. Évalué à 2. Dernière modification le 06 septembre 2019 à 13:05.
        
        Ce qui correspondrait à if (x==1)… pas vraiment ce qu'on cherche (même pas à if (x==True) à cause d'une autres finesse dans les expressions logiques) .
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
    - [^] # Re: Utilisation de Python par un profane
      
      Posté par Matthieu Moy (site web personnel) le 05 septembre 2019 à 20:48. Évalué à 4.
      
      Moi, en tant qu'enseignant, ma difficulté est de faire que les étudiants lisent tout le texte que je leur envoie plutôt que de réagir sur une ligne sans lire le reste.
      
      Et visiblement ça ne concerne pas que mes étudiants ;-).
# Allez je me lance

Posté par flagos le 04 septembre 2019 à 13:28. Évalué à 10.

Ou alors tous ces jolis graphes issus de Stack Overflow veulent juste dire que la doc Python est moisie.
# Il faut distinguer les usages et les utilisateurs dans ces statistiques

Posté par fabrices le 04 septembre 2019 à 14:07. Évalué à 8.
Contrairement à d'autre langage, Python est utilisé par un large spectre de gens
- comme un langage de haut niveau pour faire du prototype ou coder rapidement un truc qui marche
- pour des applications web en alternative à CGI Perl Php etc.
- pour des vrais applications en production qui marche si on sait utiliser le langage à bonne escient
Et surtout des gens qui ne sont pas informaticiens mais qui ont besoin d'un langage accessible et performant

Je penses que cette poussé est en partie dû au faite que les frameworks de Machine Learning utilise Python, que Numpy etc. offre une alternative à Matlab, OpenCV à un binding Python etc. etc.

Je crois que les informaticiens oublient cet aspect, Python est un bon langage pour des ingénieurs et aussi pour des « informaticiens » qui ne sont pas des experts du code (genre Visual Basic et Js cracra). Rien que l'indentation qui fait partie de la syntaxe est un plus indéniable.
- [^] # Re: Il faut distinguer les usages et les utilisateurs dans ces statistiques
  
  Posté par bistouille le 04 septembre 2019 à 15:33. Évalué à 6.
  
  Je suis du même avis, ce langage fédère nombre de profils très différents, et il est enseigné de plus en plus largement (y compris au lycée, il est enseigné dans le cadre du programme de maths actuellement).
  Pour un complet débutant, le problème principal dont il faut s'affranchir est l'indentation. Il faut trouver un éditeur permettant l'indentation automatique, c'est à dire choisir parmi un large éventail de possibilités. On a vu pire comme problématique :-)
  Avec quelques heures de lecture de tutoriel, on peut s'en sortir et écrire ses premiers programmes. La courbe d'apprentissage (à mon avis) s'élève assez lentement, de sorte qu'il est possible de produire un code suffisamment utilisable et lisible rapidement, pour résoudre des problèmes simples.
  On trouve même des implémentations de python sur microcontrôleurs (pleins de cartes à base de stm32, cartes micro::bits, esp8266, pyboard, wipy etc…).
  La syntaxe est relativement concise, c'est un peu plus ardu que dans bien d'autres langages de parvenir à un fatras de trucs illisibles (mais c'est possible quand même :-) ), et le "bestiaire" de packages disponibles est assez impressionnant.
  Donc au final ça fait consensus chez une large population d'utilisateurs, qu'ils soient des "purs et durs" du développement, des passionnés, des étudiants, ou des professionnels "à la marge" de l'informatique en quête d'outils relativement simples à mettre en oeuvre sans trop de prise de tête pour automatiser une tâche.
# lisibilité ... et enseignement

Posté par Albert_ le 04 septembre 2019 à 15:26. Évalué à 10. Dernière modification le 04 septembre 2019 à 15:26.

Les deux raisons du sucés de Python.

C'est amusant les langages avec lequel une semaine plus tard tu ne comprends pas ce que tu as écris (quand tu ne codes pas dans ce langage depuis 10 ans) mais bon au bon d'un moment c'est lassant.

Le fait que ce langage, gratuit, permette aussi bien de faire de dev web, du data science et surtout d’être utiliser très rapidement sans avoir a apprendre au préalable toute une chaîne de compilation à fait qu'il est devenu assez populaire dans les universités partout dans le monde. Et comme d'habitude ce que les étudiants apprennent c'est ce qu'ils veulent utiliser par la suite. Pourquoi croyez vous qu'il soit ultra simple de pirater des logiciels "metiers" comme matlab ou autre en tant qu'etudiant et que le jour ou le meme piratage se fait au sein d'une entite commerciale, il y a immediatement une demande de "régulation" des licences. Avec Python, plus besoin de pirater et les boites ont accepté son utilisation de ce fait, ce qui fait que depuis presque 10 ans ce langage c'est imposé dans l'industrie (en dehors de toutes ses qualités … et défaut).
- [^] # Re: lisibilité ... et enseignement
  
  Posté par 2PetitsVerres le 05 septembre 2019 à 20:19. Évalué à 0. Dernière modification le 05 septembre 2019 à 20:19.
  
  le jour ou le meme piratage se fait au sein d'une entite commerciale, il y a immediatement une demande de "régulation" des licences
  
  Là en lisant ça j'essaye de calculer le montant de mon bonus si c'était vrai.
  
  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Sa force, c'est sa communauté

Posté par Frubversion le 04 septembre 2019 à 23:35. Évalué à 4.

Et parce que, quand le code n'est pas satisfaisant à la lecture, "There must be a better way!"
# Saisonnalité du Java et du C++

Posté par martoni (site web personnel, Mastodon) le 05 septembre 2019 à 08:30. Évalué à 5.

C'est marrant cette saisonnalité du Java et du C++ dans le premier graphe.

Quelqu'un sais quelle peut en être la cause ? Est-ce que ça ne serait pas des langages «scolaire» par exemple ?

J'ai plus qu'une balle
- [^] # Re: Saisonnalité du Java et du C++
  
  Posté par barmic 🦦 le 05 septembre 2019 à 09:52. Évalué à 4.
  
  Les développeurs java se mettent aux javascript pour la periode de Noël, c'est une forme d'hibernage.
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Saisonnalité du Java et du C++
  
  Posté par Oliver (site web personnel) le 05 septembre 2019 à 18:20. Évalué à 6. Dernière modification le 05 septembre 2019 à 18:20.
  Oui, nous remarquons une baisse de la proportion de la consultation concernant Java et C++ dans la totalité du trafic web StackOverflow. Ces baisses se répètent simultanément à la même période de l’année pour ces deux langages :
  - baisse de courte durée et de petite amplitude qui coïncide avec les vacances décembre/janvier
  - baisse de plus longue et de plus grande amplitude qui coïncide avec les vacances d’été
  De façon un peu imperceptible, nous pouvons remarquer une saisonnalité contraire pour le C# et le JavaScript.
  
  Pas pour le Python, ni le PHP.
  
  Personnellement, j’en conclus :
  - Java et C++ se sont des langages utilisés par des salariés pendant leurs heures de travail
  - JavaScript et C# semblent être davantage utilisés par des hobbyistes, étudiants, stagiaires…
  - Python et PHP semblent être utilisés par tous : salariés, hobbyistes et les autres…
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
# A mon avis la réponse est simple

Posté par Christophe B. (site web personnel) le 05 septembre 2019 à 09:44. Évalué à 10.

Mon avis (qui n'engage que moi) sur ces langages : Python / Javascript / Java / C# / PHP / C++

Javascript : même avec node.js c'est pas le plus abordable des langages et loin d'être le plus lisible, qui n'a pas pété les plombs a cause d'une accolade ou d'une parenthèse mal placée ?
en plus ce langage n'était pas destiné à devenir un GRAND langage à la base.

Java : plébiscité par le milieu pro OK, mais c'est quand même verbeux et puis il y a trop de machines virtuelles différentes, ceci dit quand la mémoire est bouffée par un processus on sait d'ou cela vient.
Par contre l'éco système et les librairies sont impressionnantes, mais difficile de s'y mettre.
Bien conçu des le départ mais maintenant il s'écroule sous sa propre masse.

C# : c'est pour les fans de microsoft sinon je sais pas pourquoi il existe …

PHP : sincerement faire de l'objet avec PHP … et je disais que java était verbeux …
la aussi Pretty Home Page a commencé petit et il est devenu grand mais trop vite …

C++ : c'est un peu comme les formules 1 ou les poids lourds, tu vas pas au supermarché du coin avec …
par contre si tu veux aller vite ou faire de grandes choses …
Le C n'était qu'un assembleur amélioré, le C++ n'est qu'une surcouche au départ.

et python : simple lisible efficace, parfait pour débuter, une fois que tu l'adoptes tu le laches plus et en plus tu peu tout faire avec de gros projets, du web, du scripting de tout les jours etc …
Python a toujours eu de bonne bases solides et simples, et comme les autres il s'améliore car oui il y en encore des choses à améliorer.

"La simplicité c'est la sophistication ultime"

perso j'ai abandonné le perl pour python car maintenir un code que tu n'as pas touché depuis 6 mois est difficile en perl

vous pouvez moinssez, c'est mérité et à la limite de la caricature, mais j'ai pas pu attendre Dredi
# Possible explication de l'envolée de la popularité de Python

Posté par Victor STINNER (site web personnel) le 05 septembre 2019 à 12:58. Évalué à 10.

J'ai entendu qu'il y a une corrélation entre l'envolée de la popularité de Python et l'envolée de la popularité du {machine learning, data science, numpy, scipy, pandas, scikit-learn, etc.} : le milieu scientifique assez éloigné du développement logiciel classique.

J'ai entendu que doucement Python "remplace" plusieurs outils existants. Je ne saurai les citer, mais au pif je dirai : Matlab au moins (le seul que j'ai touché). À ce que j'ai compris, Python est supérieur aux outils existants parce qu'il est gratuit (hé oui), qu'il facilite l'intégration d'outils hétérogènes de métiers différents, et qu'il vient avec une grosse suite d'outils qui facilitent la vie (stdlib entre autres, genre lire un CSV dans un ZIP est trivial). Les notebooks Jupyter vont encore plus loin dans le remplacement de Matlab.

Quand je dis "milieu scientifique", c'est assez large. Récemment, j'ai appris que Python commence à remplacer les outils utilisés historiquement dans le domaine de l'astronomie (genre https://www.astropy.org/ ?).

En même temps, chaque fois qu'un outil s'améliore dans un métier, il peut être réutilisé dans un autre métier, parce que Python est maléable et permet de bien intéger des outils divers et variés (c'est sa force historique).

Perso je reste bluffé que le coeur de numpy/scipy reste du super vieux code (10 ans ? 20 ans ? je ne sais pas) écrit en Fortran. Info à vérifier, pas sûr des dates. Mais on m'a dit "le code marche et a été prouvé (stabilité numérique), pourquoi changer ?". Il existe des projets pour réécrire des briques de base (calcul matriciel) en C, mais l'existant en Fortran reste très populaire : OpenBLAS si ma mémoire est bonne. GitHub me dit qu'OpenBLAS est constitué de 50% de Fortran, 27% d'assembleur, 20% de C (+ qq. autres langages) : https://github.com/xianyi/OpenBLAS Ou bien peut être que je confonds avec ATLAS, une autre implémentation de l'API BLAS aussi écrite en Fortran.
- [^] # Re: Possible explication de l'envolée de la popularité de Python
  
  Posté par Albert_ le 06 septembre 2019 à 08:59. Évalué à 4.
  
  j'ai appris que Python commence à remplacer les outils utilisés historiquement dans le domaine de l'astronomie (genre https://www.astropy.org/ ?)
  
  Euh cela fait 20 ans que la transition est entamé… Les ancêtres de numpy sont numpy (v1) et numarray. Le deuxième vient du Space Telescope Science Institut.
  Le gros domaine qui reste, pour le moment, sur du C++ c'est celui des hautes energies (LHC) mais autrement pour les analyses de données Python est en train de tout manger en science avec aussi pour une partie des data sciencetist le R.
  - [^] # Re: Possible explication de l'envolée de la popularité de Python
    
    Posté par bayo le 09 septembre 2019 à 20:59. Évalué à 3.
    
    Il reste beaucoup de Fortran dans Scipy. Et c'était à une époque un gros problème pour la compiler sous Windows. Mais depuis la version 1.0, comme les versions pré-compilées pour Windows sont déployées avec pypi, ca va mieux, il y a certainement pas vraiment d'intérêt de réécrire ce qui marche et qui est maintenant utilisable partout.
    - [^] # Re: Possible explication de l'envolée de la popularité de Python
      
      Posté par Albert_ le 09 septembre 2019 à 22:18. Évalué à 2.
      
      Surtout que bon je ne vois pas qui veux s'amuser à reecrire des libs tel que atlas dans un langage bien plus complexe que le fortran et ce dans l'unique but de faire plaisir à des personnes qui ne l'utiliseront pas…
      Les parties en fortran sont extremement bien testé, solide, optimisé et utilisé de facon continue depuis depuis des decennies et cela sans le moindre souci.
      - [^] # Re: Possible explication de l'envolée de la popularité de Python
        
        Posté par barmic 🦦 le 10 septembre 2019 à 09:38. Évalué à 2.
        
        Réécrire non, mais maintenir oui.
        
        Les parties en fortran sont extremement bien testé, solide, optimisé et utilisé de facon continue depuis depuis des decennies et cela sans le moindre souci.
        
        Si tu veux pouvoir continuer à dire que c'est bien optimisé, il faut pouvoir prendre en compte à minima les instructions types SSE. Prendre en compte d'éventuels algo plus récents.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Possible explication de l'envolée de la popularité de Python
        
        Posté par Albert_ le 10 septembre 2019 à 22:06. Évalué à 2.
        
        Pourquoi? Crois tu que les compilos fortran ne sont:
        
        plus developpés?
        
        qu'il est impossible d'implémenter de nouveaux algos.
        
        Pour info, une boite un peu has been comme Nvidia vient de contribuer récemment à LLVM
        
        https://github.com/flang-compiler/f18
        
        [^] # Re: Possible explication de l'envolée de la popularité de Python
        
        Posté par barmic 🦦 le 10 septembre 2019 à 22:43. Évalué à 2.
        
        J'ai dis qu'il ne fallait pas récrire mais maintenir. Ta phrase en parlant de décennie m'a fait croire que tu disais que c'était le même code utilisé pendant plusieurs décennies, alors que je présume qu'il a bien évolué. À aucun moment j'ai parlé de récrire, juste de maintenir.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Possible explication de l'envolée de la popularité de Python
      
      Posté par Jean-Baptiste Faure le 10 septembre 2019 à 08:55. Évalué à 4.
      
      Il reste beaucoup de Fortran dans Scipy.
      
      Heureusement, car de tout ce que j'ai lu sur Python, je comprends que Python n'est efficace pour le calcul que quand ce n'est pas du Python. ;-)
# Pourquoi je n'aime pas Python...

Posté par harlock974 le 05 septembre 2019 à 15:29. Évalué à 8.

Les raisons de la popularité de Python ont été évoquées par les autres commentateurs.

C'est en effet le Basic du 21ème siècle : sa syntaxe est simple et il n'a pas besoin d'être compilé, donc il est de plus en plus utilisé dans l'éducation. Ceux qui apprennent ainsi la programmation à l'école continuent ensuite d'utiliser le même langage. Du fait de cette base éducation - recherche, de nombreuses librairies sont crées. Et Python en vient à être choisi non pas pour le langage lui-même, mais pour la présence de telle ou telle librairie. Il est par exemple très facile, et avec peu de lignes de code, d'interroger en python une base de donnée et d'afficher le résultat en environnement graphique.

Alors pourquoi je n'aime pas Python ? Pas pour des raisons techniques objectives, mais probablement un ressenti lié à une mauvaise première impression : le premier tuto que j'ai essayé pour apprendre le langage ne marchait pas, et j'ai perdu du temps dessus, tout simplement parce que le tuto était en Python 2 et mon système en Python 3. Et j'ai trouvé extrêmement léger de la part des concepteurs de changer des choses aussi basiques que la fonction Print ou l'opérateur de division. Si on essaye les tutos du livre "The C Programming Language" (écrit en 1978) avec un compilateur C actuel. Et bien ça marche.

Ensuite, la définition des blocs par indentation est une fausse bonne idée. Un copié-collé d'un exemple dans votre propre programme ne marchera pas si l'exemple indente avec des espaces et que vous indentez avec des tabulations (ou inversement). Python m'a permis de comprendre à quoi servait la fonction "remplacer les tabulations par des espaces" de Geany, dont je ne voyais pas l'utilité.

Enfin, la popularité croissante de Python fait que de plus en plus de gros programmes sont réalisé dans ce langage non compilé. Et là non plus, ce n'est pas une bonne idée de compter sur la puissance des machines.
- [^] # Re: Pourquoi je n'aime pas Python...
  
  Posté par Maclag le 05 septembre 2019 à 22:35. Évalué à 8.
  
  Et j'ai trouvé extrêmement léger de la part des concepteurs de changer des choses aussi basiques que la fonction Print ou l'opérateur de division. Si on essaye les tutos du livre "The C Programming Language" (écrit en 1978) avec un compilateur C actuel. Et bien ça marche.
  
  Je ne veux pas jouer les fanboys, mais bon:
  On tire à boulets rouges sur les langages qui ont des syntaxes alambiquées (JS et ses == vs ===, hum…), et on loue les langages dont la syntaxe est cohérente.
  Alors quand la communauté d'un langage accepte de faire une transition douloureuse en abandonnant la compatibilité ascendante pour revenir à une base cohérente, on ne devrait pas tirer dessus.
  Et je ne pense pas que ces changements justifient un changement de nom complet non plus. Python3 reste du Python avec le même esprit Python ("à chaque problème, il devrait y avoir une solution, et de préférence évidente" ou quelque chose dans le genre).
  
  Enfin, la popularité croissante de Python fait que de plus en plus de gros programmes sont réalisé dans ce langage non compilé. Et là non plus, ce n'est pas une bonne idée de compter sur la puissance des machines.
  
  Là aussi, je me demande dans quelle mesure ça se voit en pratique. Je ne cesse de lire que les benchmarks sont peu représentatifs des programmes de la vie réelle.
  De plus, en Python on appelle souvent des bibliothèques écrites dans des langages compilés et très optimisées pour les calculs les plus complexes.
  
  Est-ce qu'on voit vraiment une tendance sur les applis faites en Python?
- [^] # Re: Pourquoi je n'aime pas Python...
  
  Posté par Albert_ le 06 septembre 2019 à 09:08. Évalué à 5. Dernière modification le 06 septembre 2019 à 09:13.
  
  Le langage a évolué et a corrigé des problèmes de "jeunesse" et c'est très bien!
  
  En ce qui concerne la comparaison avec le C c'est mignon mais cela n'a rien avoir… Tu compares un langage des très bas niveau et très "simple" dont l'evolution a été arrété parceque remplacé par le C++ ou autre dans ses aspects moins bas niveau (bon courage pour refaire les tutos des premières versions C++), avec un langage de haut niveau.
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par flan (site web personnel) le 06 septembre 2019 à 21:02. Évalué à 7.
    
    Je suis d'accord : la transition a été douloureuse, mais elle était absolument nécessaire.
    Le print n'est absolument pas un problème (plein d'outils peuvent le corriger automatiquement, comme 2to3).
    Le vrai problème a été posé par la transition unicode vers str. À côté de ça, le reste des incompatibilités ne coûte rien à corriger. C'était le point à corriger, et quitte à le corriger, autant corriger tous les autres points mineurs (dont print).
    
    Expérimentalement, je constate qu'une grande partie des bugs que je rencontrais en Python 2 ont disparu en Python 3 grâce à cette transition.
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par Anonyme le 06 septembre 2019 à 21:48. Évalué à 1. Dernière modification le 06 septembre 2019 à 21:48.
    
    Le langage a évolué et a corrigé des problèmes de "jeunesse" et c'est très bien!
    
    D’un autre côté, je trouve aberrant que async et await soient devenu des mots clés dans une version mineure (3.7) et je suis pas le seul : La débâcle de async en 3.7.
    - [^] # Re: Pourquoi je n'aime pas Python...
      
      Posté par Albert_ le 06 septembre 2019 à 22:30. Évalué à 2.
      
      Ouais enfin par rapport au cassage de str ça c'est très très mineure comme changement.
- [^] # Re: Pourquoi je n'aime pas Python...
  
  Posté par Christophe B. (site web personnel) le 06 septembre 2019 à 10:15. Évalué à 6.
  ce n'est pas une bonne idée de compter sur la puissance des machines.
  
  C'est le seul point sur lequel je suis d'accord avec toi
  
  Sinon python2 python3 cela reste du python mais en mieux plus logique
  
  L'indentation : cela oblige a structurer le code et c'est un vrai bonne idée
  la preuve quasiment tout les langages ont des outils pour améliorer / formatter / standardiser la lecture du code (même python)
  
  Python comme tout les langages demande un peu d'investissement, et pour être honnête moi aussi je suis passé à coté (version 1.5 il y a longtemps …)
  
  Puis en lisant un bout de code ou une explication sur l'objet je tombe sur la syntaxe suivante :
```
class Vide():
    pass

a = Vide()
a.toto = 1
b.truc = 2
```
  Une lumiere s'est allumé en haut, j'ai entendu de la musique bref l'illumination … enfin un langage permettant de créer des structures vides que l'on peut completer par la suite.
  
  Le but : écrire du code sans trop réfléchir et être obligé de tout poser sur papier
  
  comme quand on dessine une tête, on fait une patate ou un oeuf (cela dépend de la tête :) )
  puis on dégrossit, on affine.
  des que le brouillon est presque correct on passe au feutre les lignes importantes pour obtenir quelque chose de propre.
  
  Peu de langage permette ce genre de choses
  
  Et c'est ce que j'aime dans python, c'est toi qui decide pas la syntaxe, python par défaut considère que le codeur sait ce qu'il fait.
  
  Autre exemple : il n'y a pas de propriétés ou d'attributs privés, tout est public, par convention si le nom commence par '_' c'est a considérer comme privé, mais rien ne t'y oblige c'est juste une convention.
  Il n'y a rien à cacher juste des grands garçons et de grandes filles : des codeurs responsables
  
  si tu veux de la structure et un compilateur/interpreteur qui te corrige tes conneries faut aller voir du coté du langage ADA, tu seras pas déçu.
  
  Cependant cela correspond peut être à MA manière de voir les choses, heureusement il y a BEAUCOUP de langages pour tout les goûts et c'est une bonne chose.
  
  Mais python mérite que l'on s'y attarde …
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par barmic 🦦 le 06 septembre 2019 à 11:18. Évalué à -1.
    
    Une lumiere s'est allumé en haut, j'ai entendu de la musique bref l'illumination … enfin un langage permettant de créer des structures vides que l'on peut completer par la suite.
    
    Le but : écrire du code sans trop réfléchir et être obligé de tout poser sur papier
    
    comme quand on dessine une tête, on fait une patate ou un oeuf (cela dépend de la tête :) )
    puis on dégrossit, on affine.
    
    Ce que tu cherche, ce n'est pas python, mais un langage à prototype comme javascript.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Pourquoi je n'aime pas Python...
      
      Posté par Albert_ le 06 septembre 2019 à 22:27. Évalué à 3.
      
      Petit comique va. Faire du JavaScript c'est uniquement quand tu n'as pas le choix. Il faut être atteint du syndrome de Stockholm pour développer volontairement, en dehors du web car tu n'as pas le choix la, en JavaScript.
      
      J'avais beaucoup aimé une vidéo montrant les message complètement differents pour des objets vide… Amusant, très amusant…
      - [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par barmic 🦦 le 06 septembre 2019 à 23:12. Évalué à 0.
        
        Donc personne n'utilise node ?
        
        JS n'était pas le sujet de mon commentaire juste un exemple. La logique de construction de structures qu'il décrit c'est de l'objet par prototype.
        
        Je ne suis pas du tout fan, mais si les gens qui crachent sur js prenaient le temps de s'intéresser à sa avant d'essayer de coder en js, comme on code dans leur autre qui est trop bien, ça se passerai probablement mieux (pas parfaitement, mais mieux). On ne code pas contre un langage, mais avec.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par flan (site web personnel) le 06 septembre 2019 à 23:32. Évalué à 1.
        
        J'ai beau chercher, je ne vois vraiment pas l'intérêt de cette construction. C'est différent d'à peu près tous les autres langages objet (rien que ça, c'est un gros défaut car il est naturel de vouloir réutiliser les concepts déjà connus), alors que le seul intérêt affiché est de pouvoir changer dynamiquement d'héritage… je sens le truc qu'il ne faut surtout pas faire en pratique (intuitivement, si un objet a besoin de changer tout le temps de parent, c'est qu'il y a un petit souci quelque part…).
        
        Et ça, c'est sans parler des autres trucs qui ressemblent à ce que font les autres langages mais en fait ce n'est pas pareil. Par exemple {toto: "titi", tata: "tutu"} est la même chose que {"toto": "titi", "tata": "tutu"} (donc parfois mettre des guillemets ne change rien — je n'ai jamais vu ça ailleurs) et bien sûr c'est un objet avec les propriétés "toto" et"tata" et surtout pas une HashMap (ou dict pour les Pythonnistes) qui serait écrite Map([[ "toto", "titi" ], ["tata", "tutu"]]).
        Bon, personne n'utilise l'objet Map officiel (sans rire, je ne l'ai jamais vu utilisé) et tout le monde utilise des {} comme des HashMap.
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par Albert_ le 07 septembre 2019 à 15:46. Évalué à -2. Dernière modification le 07 septembre 2019 à 15:48.
        
        Ben oui on peut meme faire du calcul numerique en bash… ce n'est pas pour cela que c'est bien meme si cela fonctionne.
        
        Les apps node and co c'est pour réutiliser le merdier du web sur le desktop. Apres on peut aimer ca ou trouver ca tres tres sale :)
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par barmic 🦦 le 07 septembre 2019 à 16:03. Évalué à 0. Dernière modification le 07 septembre 2019 à 16:03.
        
        Hé hé ok. J'explique objectivement que ce qu'il apprécie possède un modèle théorique et des implémentation. Je donne comme exemple l'implémentation la plus utilisée, et tu réponds juste "lol j'aime pas js" ?
        
        Très bien on a compris ton avis. Merci de l'avoir partagé avec nous.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par Albert_ le 08 septembre 2019 à 00:38. Évalué à -2.
        
        Mais si tu trouves les incohérences de js bien c'est cool. Tu peux aussi accepter les personnes qui préfèrent avoir des trucs cohérent s dans un langage.
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par barmic 🦦 le 08 septembre 2019 à 00:49. Évalué à 1.
        
        Je n'ai pas donné mon avis. À aucun moment, nul part. J'ai pointé du doigt la programmation objet par prototype pour informer quelqu'un qui me semble pouvoir être intéressé. Nos avis respectifs sur l'une des implémentations n'ont rien à voir surtout quand ils ne parlent pas du système de prototype en particulier, mais juste d'avis général de contoire.
        
        Je vois pas ce qui dans mon commentaire initial t'a fais te dire : "tiens quelqu'un parle de ce langage que je n'aime pas, il fait que je dise que je ne l'aime pas même si ça n'a rien à voir avec le sujet".
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par barmic 🦦 le 08 septembre 2019 à 00:53. Évalué à 0.
        
        Si vraiment tu veux mon avis, je déteste js et je n'ai pas vu d'endroit où il est nécessaire. Dans le navigateur je compile vers js, comme je compile en assembleur ou en bytecode mes autres programmes. J'utilise typescript ou elm selon les projets.
        
        Mais c'est mon avis ça n'a rien à voir avec le fait qu'il existe des objets à prototypes et que ça intéresse des gens.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par Marco le 06 septembre 2019 à 12:16. Évalué à 2.
    
    L'indentation : cela oblige a structurer le code et c'est un vrai bonne idée
    
    Ca le rend aussi très agréable à lire, ce qui n'est pas négligeable.
    
    Il est également très agréable à écrire. Autre chose non négligeable : tu peux écrire les commandes une par une sur une console python. Parfait pour apprendre et comprendre ce qu'il se passe.
    
    Autre exemple : il n'y a pas de propriétés ou d'attributs privés, tout est public, par convention si le nom commence par '_' c'est a considérer comme privé, mais rien ne t'y oblige c'est juste une convention.
    
    Tu peux utiliser un double _ qui t'empêche d'y accéder trop facilement, oui ca reste accessible mais celui qui le fait ne pourra pas dire qu'il ignorait de taper dans du privé.
    - [^] # Re: Pourquoi je n'aime pas Python...
      
      Posté par Albert_ le 07 septembre 2019 à 15:50. Évalué à 3.
      
      Fait un peu d'archeologie de code ou recupere du code fait par des porcs et tu verras l'avantage d'avoir un code structuré proprement des le depart!
      En effet, le devs "peut" indenter son code … ou pas!
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par harlock974 le 07 septembre 2019 à 06:57. Évalué à -1.
    
    Mais python mérite que l'on s'y attarde
    
    Je ne dis pas le contraire. C'est un excellent langage de script. Probablement le plus complet actuellement.
    - [^] # Re: Pourquoi je n'aime pas Python...
      
      Posté par Albert_ le 07 septembre 2019 à 15:47. Évalué à 2.
      
      Le python est aujourd'hui au dela du langage de script. C'est un véritable langage de programmation qui peut etre utilisé à peu pres partout sauf dans la programmation systeme.
  - [^] # Re: Pourquoi je n'aime pas Python...
    
    Posté par harlock974 le 07 septembre 2019 à 07:07. Évalué à 0.
    
    L'indentation : cela oblige a structurer le code et c'est un vrai bonne idée
    Ca le rend aussi très agréable à lire, ce qui n'est pas négligeable.
    
    Oui c'est très bien d'indenter, mais le programmeur peut le faire lui même. Ma remarque vient d'une perte de temps désagréable lors de mes débuts en Python où une espace s'est cachée dans le code et je ne comprenais pas pourquoi ça marchait pas.
    
    L'interpréteur devrait assimiler tabulation et groupes d'espaces de même longueur.
    - [^] # Re: Pourquoi je n'aime pas Python...
      
      Posté par lolop (site web personnel) le 07 septembre 2019 à 11:49. Évalué à 2.
      
      Sauf que la correspondance tabulation / nb d'espaces est un réglage de l'éditeur (ou du terminal quand on dump). Donc non.
      
      Il me semble que Python refuse maintenant l'exécution d'un script mélangeant les deux (flegme de vérifier — mon éditeur est configuré pour n'utiliser que des espaces).
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par lym le 07 septembre 2019 à 21:09. Évalué à 3.
        
        Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
        
        Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
        
        Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
        
        Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
        
        Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
        
        Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par lolop (site web personnel) le 07 septembre 2019 à 21:53. Évalué à 4.
        
        Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.
        
        En Python il s'en sort très bien, en effectuant ce que le programmeur a signifié par l'indentation. Si un éditeur n'est pas capable de remplacer chaque tabulation par 4 espaces, changer d'éditeur.
        
        Je viens de tester le mix tab et espace :
        
        laurent@litchi:~$ python3 toto.py File "toto.py", line 4 print("titi") ^ TabError: inconsistent use of tabs and spaces in indentation
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par bayo le 09 septembre 2019 à 21:23. Évalué à 1.
        
        Oui, il me semble que c'est un des changements de la transition Python2/Python3.
        
        [^] # Re: Pourquoi je n'aime pas Python...
        
        Posté par lym le 11 septembre 2019 à 08:17. Évalué à 0.
        
        Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
        
        Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
# Retour sur des grosses applications

Posté par fsx999 le 06 septembre 2019 à 15:13. Évalué à 5.
Je fais du python en environnement professionnel depuis 2010 et je ne fais que ça en backend (pour les fronts je suis passé par les moteurs de template mvc puis de l'angularjs puis angular).

Durant cette période j'ai participé à trois gros projets, le premier en python 2, les deux autres en python3, chacun ayant dépassé les 300 000 lignes de codes pour un nombre d'utilisateurs d'environ 20 000 personnes.

Pourquoi avoir choisi Python à l'époque :
- Un code lisible
- Une technologie facile à apprendre
donc en tant que responsable d'équipe, une facilité à intégrer des personnes dans le projet, et pour un projet de plusieurs années c'est une chose super importante.
- un langage utilisé pour le dév backend web
- un langage utilisé par les datascientists
- un langage utiliser par les devops/sysadmin
Encore une fois pour un groupe c'est important, ça permet plus facilement de permettre à des personnes de monter en compétence (des datascientists voulant faire du back par exemple).

Bref dans une entreprise, ce genre de technologie (et à ma connaissance c'est la seule, nodejs ne fait pas encore de datascience (et encore avec tensorflowsj)) est un avantage certain pour le management d'une équipe et d'un projet.

Le manque de typage n'a jamais été un problème comme j'ai pu le ressentir avec le js (l'arrivée d'angular/typescript a tellement changé la donne) même si j'avoue que des fois j'aurais bien aimé que le typing soit arrivé un peu plus tot.

Aujourd'hui je travaille dans une société gérant des métriques, nous avons des milliers de connexions par seconde, et le serveur ftp écrit en python, ainsi que l'ensemble de prétraitement géré par celery (on parle de plusieurs millions d'écriture par jours) ne posent aucun problème de performance.
- [^] # Re: Retour sur des grosses applications
  
  Posté par Kwiknclean le 06 septembre 2019 à 20:51. Évalué à 4.
```
Aujourd'hui je travaille dans une société gérant des métriques, nous avons des milliers de connexions par seconde, et le serveur ftp écrit en python, ainsi que l'ensemble de prétraitement géré par celery (on parle de plusieurs millions d'écriture par jours) ne posent aucun problème de performance.
```
  Bon là j'ai tiqué.
  
  Performance , Python … faut quand même pas trop être pointilleux et faut pas trop avoir besoin de performance non plus.
  Wé effectivement sur des VM Bardée en RAM et en Core la ou un outil comme PureFTPd aurait fait largement tout aussi bien mais avec 10 fois moins de ressource … C'est sur du Stockage type Full Flash voir NVME la base de donnée elle tourne bien c'est sur.
  
  Ca compense les logiciels chronophage dans leur execution, les millions de cycles CPU perdus les dizaines de Giga de RAM qu'il faut fournir car on a affaire à des chefs de projets qui te font des outils "systèmes performant" en Python !
  
  Je ne supporte plus les outils codés dans ce langage qui te bouffent des Centaines de méga de mémoire ou il faut charger des dizaines lib pip truc, et qui fout à genoux une machine standard dés qu'il s'agit d'aller manipuler des fichiers de plus de quelques milliers de lignes.
  
  Revenez à l'informatique bordel, revenez à la performance, sauvez la planète arrêtez Python !
  - [^] # Re: Retour sur des grosses applications
    
    Posté par Anonyme le 06 septembre 2019 à 21:51. Évalué à 0.
    
    Je ne supporte plus les outils codés dans ce langage qui te bouffent des Centaines de méga de mémoire ou il faut charger des dizaines lib pip truc, et qui fout à genoux une machine standard dés qu'il s'agit d'aller manipuler des fichiers de plus de quelques milliers de lignes.
    
    On dirait que tu parles de Go, c’est marrant.
    - [^] # Re: Retour sur des grosses applications
      
      Posté par Christophe B. (site web personnel) le 08 septembre 2019 à 10:21. Évalué à 1.
      
      Moi je dirais qu'il parle de Windows …
  - [^] # Re: Retour sur des grosses applications
    
    Posté par flan (site web personnel) le 06 septembre 2019 à 21:57. Évalué à 6. Dernière modification le 06 septembre 2019 à 21:58.
    
    Bof.
    
    D'une part, ce n'est pas parce que tu codes en Python que ton CPU va passer son temps dans du Python (si le cas s'y prête bien, ton code passera son temps soit à faire des E/S, soit dans du code hyper optimisé en C ou tout autre langage performant).
    
    D'autre part, c'est bien joli de dire qu'il faut faire du code optimal, mais combien de temps cela prend-il ? Bah oui, pour prendre mon petit cas personnel au boulot (et en perso, d'ailleurs), le code est très souvent sous-optimal et je le fais ainsi en toute connaissance de cause. Simplement, ça coûterait beaucoup plus cher de faire du code optimisé (en plus d'être parfaitement inutile).
    - [^] # Re: Retour sur des grosses applications
      
      Posté par barmic 🦦 le 06 septembre 2019 à 23:15. Évalué à 1.
      
      Ça fait plusieurs fois que je vous des gens parler du code C très optimisé utilisé avec python… On peut interfacer python avec une bibliothèque C pas très optimisé ou ça ne marche pas ? 😊
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: Retour sur des grosses applications
        
        Posté par flan (site web personnel) le 06 septembre 2019 à 23:34. Évalué à 2.
        
        C'est surtout que quand on fait du calcul intensif avec Python, ce sont toujours les mêmes bibliothèques qui reviennent (coucou NumPy) et celles-ci sont a priori plutôt bien travaillées.
  - [^] # Re: Retour sur des grosses applications
    
    Posté par fsx999 le 07 septembre 2019 à 03:43. Évalué à 3.
    
    Non, juste une vm avec 8 giga de ram, un proc ordinaire.
    
    Pour info, des qu'une partie de ton code est problématique en python tu peux utiliser du c / rust pour l'implémenter en python. Tu peux aussi directement appelé des fonctions systèmes du noyau linux par exemple.
    
    Ici https://pyftpdlib.readthedocs.io/en/latest/benchmarks.html tu as une comparaison des perfs.
    
    La totalité de ce que j'ai énoncé plus haut est extrêmement léger.
    Le premier projet est héberger depuis 2011 sur un server de 8 giga de ram avec un proc deux coeur (soit 4 threads), base de donnée comprise, et à même eu une transition docker en 2016.
    
    De mon expérience, j'ai vu une multitude de programme en java tous plus lourds les uns que les autres, remplis de fuite de mémoire (si ce n'est pas parce qu'il y a un grabage collector qu'il ne peut pas avoir des fuites, tout comme python ou javascript). Je ne parle pas des programmes en c/c++ encore pire que tout, codé avec ses pieds.
    
    Je me souvient de l'époque de transition entre apache/modwsgi => nginx en reverse proxy + gunicorn (un serveur python écrit en python) : sur la machine de 8 giga j'ai gagné 4 giga de fuite mémoire qui se produisait (la raison de la migration).
    
    Bref, non et non, on peut faire du python performant, non gourmand en ram ou proc, et quand c'est nécessaire faire appel à des libs utilisants une implémentation compilée (numpy par exemple) ou les écrire (c'est hyper facile en rust)
- [^] # Re: Retour sur des grosses applications
  
  Posté par flan (site web personnel) le 06 septembre 2019 à 21:04. Évalué à 4. Dernière modification le 06 septembre 2019 à 21:04.
  
  Un autre avantage : tout le monde (ou presque) code en Python de la même façon, en respectant (plus ou moins) la PEP008 sur la norme de code. J'ai très rarement des problèmes pour me plonger dans le code des autres (bien moins que dans d'autres langages).
  Certes, on peut faire du Python avec des tabs ou 5 espaces par indentation… mais je ne me souviens pas en avoir rencontré.
  
  L'utilisation de black va encore augmenter ça, je pense.
  - [^] # Re: Retour sur des grosses applications
    
    Posté par Anonyme le 06 septembre 2019 à 21:53. Évalué à 2.
    
    tout le monde (ou presque) code en Python de la même façon, en respectant (plus ou moins) la PEP008 sur la norme de code.
    
    Ouais, enfin, on est encore loin de Go et son go fmt. black est vraiment cool pour ça, mais encore trop peu connu.
    - [^] # Re: Retour sur des grosses applications
      
      Posté par flan (site web personnel) le 06 septembre 2019 à 22:33. Évalué à 1.
      
      Oui, on est d'accord, mais la PEP008 est déjà pas mal. Avec un peu de chance, black deviendra un outil officiel :)
  - [^] # Re: Retour sur des grosses applications
    
    Posté par lym le 07 septembre 2019 à 21:17. Évalué à 1.
    
    Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
    Forcément, là le style on s'en fout car la grammaire est robuste.
    
    Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
    
    Après cela, on a beau jeu de dire que le C est dangereux…
    - [^] # Re: Retour sur des grosses applications
      
      Posté par flan (site web personnel) le 07 septembre 2019 à 21:55. Évalué à 1.
      
      Personnellement, je n'ai pas souvenir avoir de bugs liés à l'indentation, et encore moins à cause d'un mélange d'espaces et de tabs. Alors, certes, j'utilise un IDE utile, à nouveau…
    - [^] # Re: Retour sur des grosses applications
      
      Posté par GuieA_7 (site web personnel) le 07 septembre 2019 à 22:41. Évalué à 3.
      
      ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
      
      Sans doute… ou pas. S'il y en a des "tétra-chiées" tu ne devrais pas avoir de problème à nous en indiquer quelques uns.
      
      Après cela, on a beau jeu de dire que le C est dangereux…
      
      Parce que des vulnérabilités dans du code C ayant mené à des soucis énormes de sécurité (entre autres) ce n'est pas difficile, il y en a beaucoup. Par exemple les différentes failles dans OpenSSL de ces dernières années (Heartbleed et compagnie) ; évidemment C est très utilisé (et pas au mêmes endroits que Python, donc difficile de comparer), et aucun langage n'empêchera jamais de coder salement etc… donc je ne vais pas tout mettre sur le dos du C. Mais l'existence de "tétra-chiées de bugs fort coûteux" est sans appel.
      
      Reste que dire que C est plus fiable que Python pour une raison de re-formatage du code source c'est assez ridicule. J'écris du python depuis 2004 (et à temps plein de puis 2009) et j'ai du être piégé une poignée de fois par un problème d'indentation foireuse, et j'ai au pire perdu quelques minutes à trouver pourquoi mon code ne marchait pas ; ça n'a jamais donné lieu à un bug qui explose chez un utilisateur. Peut-être parce que je teste mon code, j'évite de le committer directement avoir l'avoir écrit (un buffer-overflow il faut passer à un niveau supérieur niveau test, genre fuzzing, pour les trouver efficacement, c'est très loin d'être trivial). Il y a des tas de vrais problèmes dans python, mais "ohalala j'ai copié-collé 3000 lignes de codes trouvées sur le Web, j'ai pas testé et ça me faire du caca" n'en est pas un.
      - [^] # Re: Retour sur des grosses applications
        
        Posté par lym le 11 septembre 2019 à 08:45. Évalué à 0. Dernière modification le 11 septembre 2019 à 08:45.
        
        Tout source passé par plusieurs éditeurs dont au moins un n'était pas configuré pour transformer les tabulations en espace peut poser le problème sur la/les lignes de fin de bloc.
        
        Je ne crois par ailleurs pas avoir dit que C était plus fiable que Python. Juste que sauf bug compilo ou processeur, au moins il fait toujours ce que le programmeur voit dans son éditeur préféré. Qu'on l'évite de plus en plus partout ou il est évitable ne me pose pas de problème, mais bon, travaillant au ras des pâquerettes c'est forcément 99% de ce que je produis et si ca n'avait pas été le cas, n'importe quel autre langage utilisant des délimiteurs (cad l'immense majorité) aurait pu être pris en exemple.
        
        Vu comme on nous flique sur ce qu'on livre, surtout depuis 10 ans que blackduck repère/colle une licence sur chaque bout de code y compris compilé (=> à partir de là, n'importe quel concurrent faisant un dump de votre firmware s'il y trouvait un bout de code GPL pouvait vous obliger à en publier des pans entiers ou vous bloquer niveau vente!), pas de risque d'aller à la pêche sur le net.
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par GuieA_7 (site web personnel) le 11 septembre 2019 à 23:58. Évalué à 1.
        
        Tu affirmes que l'indentation en Python est une cause monumentale de bugs, mais tu ne nous dis toujours pas comment tu le sais. Si je comprends bien tu ne codes globalement qu'en C toute la journée donc ce n'est pas ton expérience personnelle ; et toujours aucun lien vers des gens qui font du Python et qui parlent de ce (soit-disant) gros problème (alors que des blogs qui se plaignent de l'absence de typage statique ou du GIL ce n'est pas ce qui manque)…
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par lym le 12 septembre 2019 à 06:12. Évalué à 2.
        
        J'en parle, certes sans grande expérience de ce langage, car je trouve vraiment dangereux d'avoir a ce point voulu imposer une présentation propre (ce qui en soit se défend) aux dépens de la robustesse du langage (ce qui est indéfendable).
        
        Surtout, encore une fois, que sans délimiteurs aucun outil ne peut décider automatiquement comment corriger le tir. Du C formaté cochon, en quelques milli-secondes c'est rectifiable automatiquement. Si on fait des "beautifier" de source, c'est justement pour ne pas s'emmerder à cela. Des boites les passent automatiquement, d'ailleurs, pour imposer sans douleur cette partie des règles de codage dès qu'on check-in des modifications de sa branche de dev. Simple et efficace. On peut même quand on prends des sources y coller son formatage préféré car on a le cerveau cablé depuis des années dessus, sans impact pour les autres. C'est la différence entre la mentalité BDFL, ou pas!
        
        D'autres ont souligné plus haut que python 3 semble ne plus vouloir interpréter des lignes mixant tabulations et espaces. Comme quoi je n'ai pas dû être le seul à pester là dessus et j'espère même que cette vérification est faite au niveau du source complet. Sinon une ligne ajoutée en fin de bloc pré-existant avec un éditeur non configuré à l'identique du précédent peut aussi poser problème.
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par GuieA_7 (site web personnel) le 13 septembre 2019 à 22:55. Évalué à 1.
        
        aux dépens de la robustesse du langage (ce qui est indéfendable).
        
        Ça n'est pas indéfendable de manière absolue, c'est un compromis tout à fait subjectif (que tu peux tout à fait refuser hein). Par exemple si ça provoque 0.001% (chiffre sorti de mon chapeau pour l'exemple) de bug mineurs en plus mais que ça permet d'améliorer sensiblement la beauté de l'ensemble du code (ne pas avoir à "beautifier" le code d'une bibliothèque externe que tu lis, tu te sens de base à peu près chez toi), on peut tout à fait comprendre que certains acceptent le compromis sans souci.
        
        Après je suis aussi le premier à dire que pour du code hyper critique il vaut mieux éviter le Python (et le C)…
  - [^] # Re: Retour sur des grosses applications
    
    Posté par Tit le 09 septembre 2019 à 09:45. Évalué à 8.
    
    Certes, on peut faire du Python avec des tabs ou 5 espaces par indentation…
    
    j'en déduis qu'il ne faut pas utiliser des tabs pour faire l'indentation… mais pourquoi ? ça m'aurait paru beaucoup plus logique comme choix, une tabulation pour faire une indentation c'est ce qu'on fait dans un traitement de texte par exemple, et on crie sur ceux qui utilisent des espaces pour aligner des choses, de plus utiliser 4 espaces non seulement ça utilise plus de caractères mais ça semble complétement aléatoire comme choix : pourquoi pas 3, 5 ou 6 caractères ?
    de plus ça veut dire utiliser un ide, sur un simple bloc note s'il faut taper 4 espaces, ce doit pas être très pratique… vraiment je comprend pas, utiliser la touche tab pour mettre 4 espaces plutôt que mettre un caractère tabulation, je trouve ça tordu.
    - [^] # Re: Retour sur des grosses applications
      
      Posté par barmic 🦦 le 09 septembre 2019 à 09:58. Évalué à 5.
      
      Le choix d'utiliser des tabulations ou des espaces est un débat sans fin. Chacun aura la sienne là dessus, certains expliqueront aussi qu'il faut mixer les 2 (indenter avec des tabulations et aligner avec des espaces) et d'autres proposent encore d'autres solution. D'autres encore codent en whitespace et n'ont pas ce genre de problème.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Retour sur des grosses applications
      
      Posté par lolop (site web personnel) le 09 septembre 2019 à 13:27. Évalué à 4.
      
      j'en déduis qu'il ne faut pas utiliser des tabs pour faire l'indentation… mais pourquoi ?
      
      Parce que c'est ce qui est préconisé par le PEP008. Comme ça on arrête de discuter continuellement et on retourne coder.
      
      une tabulation pour faire une indentation c'est ce qu'on fait dans un traitement de texte par exemple
      
      Un programme Python dans un IDE et un texte dans un traitement de texte, ça n'est pas la même chose.
      
      de plus ça veut dire utiliser un ide
      
      Oui. Ou un éditeur condigurable (vim, emacs, notepad++)… y'en a encore qui codent avec notepad ?
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Retour sur des grosses applications
        
        Posté par Tit le 09 septembre 2019 à 14:58. Évalué à 1.
        
        Parce que c'est ce qui est préconisé par le PEP008.
        
        Oui, bien sûr, mais ça ne me dit pas pourquoi ils ont fait ce choix, le choix inverse m'aurait paru plus logique.
        Mais bon j'insiste pas plus, surtout que je comprends que c'est un marronnier, désolé.
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par Philippe F (site web personnel) le 09 septembre 2019 à 16:30. Évalué à 5.
        
        Parce que tu gagnes un meilleur salaire si tu utilises des espaces plutôt que des tabulations!
        
        Cf https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par Philippe F (site web personnel) le 09 septembre 2019 à 16:31. Évalué à 5.
        
        Autre raison: le rendu avec des tabs va varier d'un PC à l'autre suivant comment tu as configuré ton éditeur (2 colonnes ? très courant en java ou 8 colonnes obligatoire dans le kernel linux ?). Et comment intepréter la limites de 78 caractères avec des tabs dans une ligne ? Une ligne composé de 70 tabulations et de 7 caractères alphanumériques dépasse la limite de 78 colonnes mais pas de 78 caractères…
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par Tit le 09 septembre 2019 à 17:30. Évalué à 3. Dernière modification le 09 septembre 2019 à 17:30.
        
        le rendu avec des tabs va varier d'un PC à l'autre suivant comment tu as configuré ton éditeur
        
        oui mais ça ça me semblait plutôt un avantage, chacun le configure comme il le souhaite (un peu comme un css personnalisé pour une page html)
        
        . Et comment intepréter la limites de 78 caractères
        
        mais là aussi ça fait partie des trucs que je comprends mal, cette limite
        
        mais bon ton premier commentaire m'a convaincu ;-)
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par Tonton Th (Mastodon) le 11 septembre 2019 à 07:31. Évalué à 4.
        
        . Et comment intepréter la limites de 78 caractères
        
        mais là aussi ça fait partie des trucs que je comprends mal, cette limite
        
        Une nimage vaut mieux qu'un cla
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par BAud (site web personnel) le 11 septembre 2019 à 09:21. Évalué à 2.
        
        qui se blo
        
        [^] # Re: Retour sur des grosses applications
        
        Posté par flan (site web personnel) le 09 septembre 2019 à 17:11. Évalué à 2.
        
        Il n’y a pas de raison imparable dans un sens comme dans l’autre. En revanche, la PEP008 et l’outil black (qui reformate ton code sans te donner le choix) sont des raisons objectives qui forcent mon choix. Par exemple je préfère les simples quotes mais black fait des doubles quotes : je m’y suis fait car black est super utile.