le 31 janvier 2017, Dropbox a arrêté Pyston, parce que les gars de Pyston n’avaient pas atteint l’amélioration de performance visée dans les temps, la tache s’est révélée plus difficile que prévue (ça alors, exactement comme les gars de Unladen Swallow, incroyable), et le 9 août 2016, Mozilla a donné 200.000$ à Pypy pour améliorer le support de Python 3, dont le support de Python3 est devenu très acceptable.

On peut voir qu’il y a une malédiction des implémentations alternatives de Python, toutes les tentatives échouent.

Actuellement, je développe surtout des logiciels graphiques avec PyQt (PyQt5 maintenant), et je dois dire que j’en suis pleinement satisfait. Mon plus gros programme graphique fait le traitement d’un concours international et dépasse 30000 lignes de code. J’intègre beaucoup de choses dans ces programmes, et comme ça a été dit, le code Python passe très rapidement la main à des parties codées en C ou en C++, et ça marche donc très bien. De plus, je les transforme souvent en exécutable “standalone” avec cx_freeze. Ainsi, sous Windows, avec un installeur comme innosetup, un utilisateur peut installer et utiliser ces logiciels sans savoir que c’est écrit en Python!

Si une petite partie de type mathématiques est un peu critique en rapidité d’exécution, il est facile de la traiter avec Cython pour la compiler en C ou en C++. En utilisant la méthode (peu connue) avec décorateurs pour déclarer le type des variables, le code Python n’a quasiment pas à être modifié. On peut aussi, bien sûr, compiler des modules entiers écrits en C ou en C++: CPython a la méthode dans sa doc, et pour l’avoir déjà utilisée, je confirme que ça marche!

Périodiquement, je regarde si une nouvelle implémentation ou un autre langage, me ferait gagner quelque chose dans mes développements, et jusqu’à présent, je n’ai rien trouvé de convaincant: il y a toujours quelque chose qui ne va pas: manque de bibliothèques, pas de développement récent, syntaxe dépassée (ex: Python2), pas assez mûr pour la production, etc… Mais comme je ne suis pas marié avec CPython, ça ne m’empêche pas de continuer à chercher, d’où ma présence sur cet excellent site!

… ça me fait un peu ticker ceci : si ça marchait comme ça alors la réussite de python ne se ferait pas sur le mérite technique.

De plus si je prends les langages sus-cités : Ruby et PHP souffrent des même défauts que python sur les performance : en gros ça a pas été pensé pour ça. Et c’est d’ailleurs tout l’article : python n’as jamais était pensé pour être performant et essayer de faire des JVM/interpréteur alternatif est un travail énorme qui se heurte toujours à des problèmes que l’on peut résumer par “python n’as pas été fait pour ça (à la base)”.

Mais pour Go, le langage est utilisable partout ou python est utilisable et est beaucoup plus performant comparé à python. Go n’est pas tellement plus complexe que python (dispose d’un GC performant pour que le programmeur n’est pas trop à se soucier de la gestion mémoire), gère la concurrence de manière beaucoup plus simple/intelligente/novatrice que l’asynchrone (CSP) et a l’avantage d’être typé statiquement (ho oui c’est un avantage !).

Donc bon, moi j’ai envie de dire “problem solved : use Go”.

Je sais que je suis sur un blog pro-python ce post est une mi-provocation et j’espère bien que vous allez tous m’expliquez que j’ai tords, car oui j’ai tords : quand les perf c’est pas le plus important utilisez ce que vous aimez; puis si vraiment les perf sont le plus important Go fait des sacrifices sur point comparé à d’autre langage.

Mais bon quand même, vu l’utilisation possible des 2 langages j’avais besoin de le dire, et sur un blog pro-Go ça aurait été trop facile :p

Tout doucement, je n’ai pas abandonné Python, je suis formateur officiel dans un centre de recherche si tu veux tout savoir même.

Je disais ça dans le sens où c’est quand même un aveu d’échec sur les perfs et sur le packaging…la lib async ne sauvera pas le monde…c’est nouveau en Python mais ça a 30 ans comme techno l’async…l’avenir c’est le CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes). L’asynchrone est mis en place par les langages dynamiques pour pallier leurs lacunes en terme de perf…c’est loin d’être l’avenir.

Moi non plus, je ne développe pas pour le web, enfin plus maintenant, vu comment ça me saoule et que le web “grand public” est devenu tout pourri (je suis un vieux) ;)

C’est pas plutôt avec la JVM ?

Je viens de relire les passages où tu mentionnes la JVM. Et effectivement y’a pas de confusion. Désolé j’étais un peu dans le pâté.