Il y a une tendance ces derniers temps à vouloir demander des changements dans Python pour le faire correspondre à une quelconque forme de fantasme qu’a chaque membre de chaque secte qui demande à corps et à cri telles ou telles modifications.
Sans ordre précis :
- la FP c’est la vie. Tout doit être immutable.
- je veux que tout soit asynchrone. Ouai même les boucles for. Au et puis non, filez-moi juste des appels récursifs.
- aucun programme n’est possible sans multi-core. Il me faut du multi-core. Mon problème d’érection vient du fait que mon script de 3 lignes n’utilise qu’un CPU.
- il faut changer le système d’import pour faire juste “import truc” et rien d’autre.
- les go-routine c’est trop de la balle, réécrivez tout Python pour retirer le GIL, virez asyncio et changez la syntaxe du langage.
- et je veux des lambdas multilignes, Dieu m’a dit que c’était bon.
- le typage dynamique est une honte, haskel est un vrai langage, il faut faire pareil.
- mais où est le pattern matching ?
En clair, vous ne voulez pas utiliser Python.
Alors utilisez un autre langage : Lisp, Go, Javascript, whatever, mais ne demandez pas à un chien de miauler.
Le système d’import est là aussi pour faciliter la programmation exploratoire et les scripts courts, pas juste de coder Youtube. La mutabilité permet de simplifier la formation des nouveaux venus. Tout programme n’a pas de problèmes de performances, et ceux qui en ont ne sont pas forcément résolues pas l’asyncio ou le multicore, qui rendent le code plus complexe. Le GIL rend Python rapide sur un core et facile la maintenance pour la toute petite équipe des core dev. Les restrictions syntaxiques ont un but stylistique qui tient de la philosophie du langage basée sur la facilité à lire le code. Le typage dynamique permet la rapidité d’écriture d’un code souple.
Ce sont des fonctionnalités. Pas des accidents. Des choix volontaires, conscients.
Elles se font au détriment d’autres fonctionnalités, et tiennent compte de l’héritage du passé, car on ne peut pas tout avoir. Peut-être préférez-vous les autres fonctionnalités. Vous avez le droit. Mais dans ce cas utilisez une techno qui a fait le choix de mettre ces dernières en avant, ne demandez pas à un projet qui n’a pas fait les choix que vous voulez de changer.
Est-ce que ça veut dire que Python ne va pas changer ? Qu’il va rester dans son état et ne pas se moderniser ?
Certainement pas !
En fait durant les 3 dernières années Python a énormément changé.
Toutes ces demandes sont entendues, et explorées et quand on y trouve une réponse bénéfique, celle-ci est intégrée au langage. Python 3 a été une réponse. Les types hints ont été une réponse. Asyncio a été une réponse. La 3.6 aura une réponse pour le multi-core.
Mais ces réponses se feront toujours dans le cadre de la philosophie et des contraintes du langage. Inutile d’espérer que Python se transforme en Erlang, Julia ou R, ça n’arrivera pas.
Par ailleurs, vous n’en avez probablement pas besoin. La plupart de ces requêtes sont des demandes de poney car il existe déjà des outils pour traiter ces problématiques. C’est vrai que ça peut être cool un poney, mais ce n’est pas un besoin. La PSF est généreuse en dons équestres, et on en reçoit régulièrement, mais il ne faut pas abuser : utilisez les méthodes qui existent déjà et qui fonctionnent. Ou comprenez que votre façon de faire n’est pas celles de milliers d’utilisateurs de Python qui l’utilisent ainsi parce que cette manière est optimale pour eux.
Apprenez à connaitre le langage plutôt que vouloir le muter pour qu’il comble votre TOC ou votre ignorance.
Parfois, les outils en place ne sont pas suffisants ou sont contraignants. C’est le cas pour le packaging, par exemple. Et dans ce cas, soyez patient, ou participez à la solution, ou encore prenez une autre techno. Toutes ces réponses sont valables. Taper du pied et pleurer pour un appaloosa ne l’est pas.
A quand un bon gros kickstarter pour un système de packaging suprême pour python, histoire de pouvoir leur jeter de l’argent à la gueule ?
Bonne analyse, c’est pour cela que doucement je change de langage. Pour moi, Python a fait une erreur en gérant 2 versions différentes, moi ça m’emmerde copieusement.
Sur le matériel moderne, on a du mal à exploiter le hardware. Python n’est pas facile à déployer sur les architectures modernes. Je l’utilise encore comme langage de script d’admin mais je ne démarre plus de nouveaux projets sur ce langage. En pratique, avec Go, je code aussi vite, j’exploite entièrement le matériel, et je déploie sur plusieurs plateformes en 2 claquements de doigts. J’adore Python mais Go répond de plus en plus à mes besoins. Avec les goroutines, j’atteins des performances dingues sur certains traitements. Les architectures sont simplifiées. Mes opinions n’engagent que moi et j’ai des besoins très spécifiques. Mais j’adore encore Python, rassurez-vous !
@dineptus: tu peux déjà donner de l’argent à la PSF ici : https://www.python.org/psf/donations/ L’équipe a parfaitement conscience du problème de packaging et travaille dessus, mais pas aussi longtemps qu’ils devraient, car http://sametmax.com/ecrivez-a-larc-envoyez-des-sioux/.
Cool article comme d’hab’ !
@Sam : où est-ce qu’on peut trouver des informations sur les propositions pour améliorer le packaging et/ou ce sur quoi l’équipe travaille à ce sujet ? Ça m’intéresse mais je suis une grosse feignasse et je n’ai pas envie d’éplucher les mailing lists de dev.
Merci !
Au sujet du système d’
import: je trouve personnellement que l’ajout des ModuleSpecs dans la version 3.4 a quand même pas mal complexifié le système : cf. la PEP 451.Dans l’optique KISS, je vois pas pourquoi cracher sur une refonte du système d’
import.Surtout vu les bugs tordus (mentionnés dans l’article de Brett Cannon) que le système actuel provoque.
Par packaging, vous entendez quoi ? Le fait de pouvoir packager son programme et le distribuer ?
Par packaging on entend le fait de clarifier ces choses là :
pip
easy_install
egg
wheels
@老皮 : nan la mailling list reste le meilleur endroit pour ça, car c’est le seul où les infos sont tout le temps à jour. Je pense que le format est volontairement un peu obscur pour éviter qu’une foule arrive et noie les bonnes infos dans une masse de bruit. Mais le revers de la médaille c’est que ça met une barrière à la participation.
@Cimon : améliorer oui, mais tronquer sous les prétextes qu’il annonce, c’est osé.
Comme je ne code toujours pas en python, je ne ferai que ma grammar nazi de passage.
Hey cékié, ravi de ton retour :)
L’autre poney que j’aimerais bien, c’est un truc simple et officiel pour distribuer ces applications python sur des machines qui n’ont pas forcément le python.
Parce que py2exe, ça marche à peu près, mais on n’est jamais sûr de rien.
Et du python dans les navigateurs aussi, genre “brython mais en mieux”.
Voilà, c’est ma liste de poney du Père Noël.
“packaging”
Ah oui mais j’avais pas pigé en fait.
Pour moi le packaging c’est “comment simplifier la transmission de librairies à d’autres développeurs qui ont déjà le python d’installé”.
Et la distribution c’est “comment simplifier la transmission d’un produit fini (exécutable, site web, …) à des utilisateurs qui n’ont pas le python et qui n’en veulent pas forcément”.
Transmettre des librairies, personnellement, c’est pas mon dada (ni mon poney). Mais transmettre des produits finis, oui.
Faut qu’on se sorte les doigts du cul pour le packaging et la distribution avec Python sinon on va se faire niquer par d’autres langages dans ce nouveau monde de la virtualisation, de la conteneurisation (cela dit c’est pire dans le monde Javascript). La manière dont on distribue les applications changent à fond les manettes. On va revenir aux applications en statique car ça va mieux à intégrer dans un monde de conteneurs. Il faut un truc simple pour distribuer une librairie et pour distribuer une application complète. Je voudrais un truc du genre :
python get matplotlib #pour installer une lib
python push malibdeouf # pour pousser une lib
python build # pour préparer un paquet complet prêt à être installé sur une autre machine ne disposant pas de Python
python install # pour installer une application complète
Dans un conteneur c’est facile. Il suffit de faire un truc genre un dockerfile et c’est gagné. 3 apt-get + 2 pip install et c’est installé. C’est plutôt pour distribuer des trucs aux utilisateurs non techniques que c’est chiant.
https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html