Philippe F a écrit 2214 commentaires

Il y a déjà un PEP sur le sujet. Mais ça ne résoud qu'une partie du problème. Cffi va permettre d'interfacer plus facilement des modules en C mais je suis pas sur que ça convienne à NumPy. NumPy est vraiment une addition au langage, pour manipuler des tableaux de données, faire des opérations mathématiques complexes en séries, manipuler d'autres types de nombres. Quid aussi du Garbage Collector, je sais pas trop comment c'est géré.

Je pensais aussi à PyQt, je serai curieux de voir ce que Cffi pourrait faire pour un tel projet.

Un résumé de l'état de Jython a été posté sur Python-dev, pour ceux qui veulent connaitre des détails sur le projet. Il a pas l'air mort puisque pas mal de projets sont en route, mais on sent pointer le manque de ressources:

https://mail.python.org/pipermail/python-dev/2014-April/133944.html

La comparaison avec Javascript n'est pas tout à fait honnête. Dans le cas de javascript, les accès au navigateur se font par des API normalisées. Donc on peut substituer n'importe quelle implémentation à une autre, ça ne perturbe pas le code Javascript.

CPython ne peut pas faire évoluer son GC mais en même temps, il n'a pas vocation à le faire. Une implémentation de référence, c'est bien quand c'est stable. Toutes les autres implémentations ont un GC différent. Elles devront juste trouver des ruses de malade pour rester compatible avec l'API GC de CPython…

Lors de la PyCon 2014, il y a eu quelques mises à jour sur les sujets que j'ai abordé:

Pyston

L'auteur a maintenant publié une FAQ, qui répond à différents aspects un peu flous du projet: http://blog.kevmod.com/2014/04/pyston-faq/

• Guido van Rossum, bien que travaillant chez Dropbox, n'intervient pas sur le projet.
• Ses plans sur les modules d'extensions sont peu clairs: il vise la compatibilité source à 100% avec les modules existants (juste une recompilation nécessaire) sans être complètement sur de la faisabilité.
• sur le GIL et le threads, il confirme qu'il ne sait pas quel modèle de thread il va utiliser ni comment il va s'y prendre, mais il pense vaguement pouvoir le faire.

Je maintiens donc mon scepticisme sur l'approche, et l'aspect très expérimental de ce projet. J'attendrai que Pyston fasse ses preuves avant de croire qu'il puisse changer quelque chose au paysage Python actuel.

IronPython

La communauté commence à prendre en main le projet, et de nouveaux contributeurs ont rejoint le projet. Le portage vers Python 3 est en cours, le projet se porte globalement bien.

Jython

Le port vers Python 3 est entamé, ainsi qu'une adapatation de cffi, le module qui permet d'interfacer directement des bibliothèques dynamiques. Des travaux sur l'intégration de PyPi (le dépot officiel de programmes Python facilement installables) ont également commencé. Le projet souffre en général d'un manque de contributeurs.

PyPy

Dernier succès: 1 million de téléchargement pour la dernière version de PyPy, compatible avec Python 2.7.6 . Une version compatible Python 3.2 est presque prête, il reste 3 bugs à corriger. Il va y avoir une nouvelle levée de fond pour les Transactions Mémoires

Tu as raison sur le fond pour les modules d'extensions: ils ont été conçus pour s'interfacer avec CPython (dans un temps immémorable où CPython n'était que l'unique implémentation de Python) et pas du tout pour être indépendants de l'implémentation. Notamment, le durée de vie des objets, même dans les modules d'extensions, est gérée par le comptage de référence, c'est à dire par le Garbage Collector de CPython.

Etre compatible avec CPython veut dire fonctionner avec le Garbage Collector de CPython ou gérer ça de façon très astucieuse. C'est ce qu'a fait PyPy, en proposant un modèle mixte pour les modules d'extension. Si je me souviens bien, ils utilisent le encore le ref-counting mais c'est le Garbage Collector classique qui collecte les objets une fois les références épuisées. Donc on y est presque (c'est le module cpyext), mais apparemment, toute l'API CPython n'est pas implémentée.

Pyston veut aussi conserver la compatibilité totale avec les extensions, avec des bidouilles autour du refcounting. Leurs plans sont malheureusement très théoriques et il faudra attendre qu'ils s'y mettent pour savoir si leur approche tient la route.

Pour résoudre ce problème de fond, les auteurs de PyPy ont écrit (bien avant PyPy) deux modules d'interfaçage avec des bibliothèques: ctypes et maintenant cffi. Les deux permettent d'appeler très facilement, sans compilation, des bibliothèques dynamiques. Ca résoud un cas majeur d'utilisation des modules d'extensions, à savoir interfacer des libs existantes écrites en C. Cffi est compatible avec PyPy, et bientôt avec Jython. On peut donc espérer à terme réduire la surface du problème.

Côté CPython, un effort a été fait pour réduire le nombre de symboles CPython exposés, afin de proposer une compatibilité plus simple avec CPython. L'objectif est plus modeste, permettre la compatibilité des modules d'extensions avec plusieurs versions de CPython en même temps.

Sur la première partie de la dépêche, j'ai vraiment cherché à rester objectif, rassemblant toutes les informations dont j'ai connaissance, sans y mêler mon opinion.

Sur la conclusion, c'est un choix partisan de fait. L'objectivité m'ennuie en général, je préfère largement le débat d'idées ! Dommage d'ailleurs que ce soit publié un dimanche et pas un vendredi ;-)

Et puis, mieux vaut une dépêche subjective assumée que des points de vues prétendument objectif que essaient d'enfumer tout le monde. La mécanique quantique nous a d'ailleurs largement prouvée s'il en était encore besoin que la notion d'objectivité n'existe pas !

Je ne pense pas que le multi-process résolve tous les cas, et ce n'est pas ce que j'ai écrit. J'ai juste rappelé que d'une part, que:

1. il y existait d'autres solutions possibles que le multi-thread pour gérer des programmes CPU-bound . Le module multiprocessing fournit un service transparent pour partager des données et lancer des opérations sur plusieurs processus. Ca peut toutefois poser des limites si la quantité de données à partager est importante, mais c'est un problème pas moins difficile à résoudre que d'écrire de programme multithreads sans bugs.

2. Beaucoup de programmes qui utilisent les threads sont IO-bound (on gère des opérations bloquantes) et dans ce cas, les threads en Python marchent très bien.

Un autre aspect sur le GIL qu'on peut rappeler, c'est que retirer le GIL sans affecter les performances des programmes mono-threads est extrèmement difficile. Sans verrou global, il y aura une multiplicité de verrous locaux à utiliser, ce qui dégrade le cas mono-thread.

Pour l'instant, à part une solution miracle que nous sortirait PyPy, le GIL est là pour rester

Dans ce cas, présis, ça a un sens d'avoir un entier associé avec le niveau de log. Tu peux ainsi définir assez facilement la notion de "tous les messages avec un niveau de log supérieur à ERROR" (ERROR + FATAL), "tous les messages avec un niveau de log supérieur à INFO" ( = INFO + WARNING + ERROR + FATAL).

Cela dit, ton besoin d'un symbole abstrait (si je l'ai bien compris) est justement couvert par l'ajout du module Enum à Python 3.4 :

>>> from enum import Enum
>>> Animal = Enum('Animal', 'ant bee cat dog')
>>> myPet = Animal.ant
>>> yourPet = Animal.beee
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    yourPet = Animal.beee
  File "C:\Python34\lib\enum.py", line 236, in __getattr__
    raise AttributeError(name) from None
AttributeError: beee
>>> 

Et tu gagnes en plus une vérification syntaxique à l'assignation de ta variable et non pas à son utilisation…

Pour reprendre ton exemple plus haut en ruby, par exemple, si tu remplaces :WARNING par :WAAAARNING, l'erreur ne sera visible que au niveau du h.setLevel(i) et pas lors de l'énumération des champs possibles.

Si Python utilisais un Enum pour gérer ça, tu aurais un logging.LogLevels = Enum('DEBUG', 'INFO', 'WARNING', 'ERROR' ) et tu pourrais faire :

for i in logging.LogLevels:
    ...

Mais globalement, si on regarde ça d'un peu plus haut, les différences sont globalement mineures et ne transforment pas massivement ni l'expressivité, ni la fonctionnalité dans un langage ou dans un autre.

Bref, c'est de l'enc******* de mouche .

asyncio, c'est vraiment la killer-feature de cette nouvelle version. Ca pourrait à lui seul justifier que des projets emprisonnés dans Python 2.7 passent en Python 3! Sauf que … il existe un backport Python 2 !

Finalement, presque la totalité des goodies de la lib de Python 3.4 sont disponibles sous forme de backport pour des version inférieures, et notamment Python 2.7 . Et côté évolution du runtime ou du langage, les évolutions ont l'air utiles mais ont relativement peu de chances d'impacter le développeur python "moyen" qui ne pousse pas Python dans ses retranchements. Ah si quand même, les évolutions autour de SSL, va vaut le coup.

Les entrées:

• un document word qui est une spec de test assez générale
• un document html généré par ma suite de test Python qui est le plan de test exact.

Evidemment, si je peux me passer de générer le html du plan de test, c'est encore mieux. Dans ce cas, un **/test_*.py est parfait.

Je suis tout à fait d'accord. Et c'est idem pour les machines à laver, les lave-vaisselles, les fours, etc etc.

Mon point de vue est qu'il va falloir un jour rependre ça en main et que c'est pas l'industrie qui va le proposer. Ca va donc être à nous, les particuliers, de nous réapproprier ces produits. On en voit l'émergence avec les FabLab. J'imagine très bien que dans quelques années on pourra se fabriquer soi-même ce type d'engin, voire trouver des boites qui comme les distrib linux, te fournissent du matériel Open Source, de la maintenance et des pièces détachées pour ce genre de produit.

On pourrait penser qu'une voiture sera impossible à faire dans ce mode. Et bien non, c'est déjà en cours et pas mal avance: http://wikispeed.org/ . La caractéristique numéro 1 d'une voiture wikispeed, c'est que toutes les pièces sont remplaçables en moins de 3h. On peut notamment substituer complètement le moteur assez facilement.

Je suis dans une petite boite où on a une approche assez pragmatique et peu formelle du développement. Pourtant, même dans ce contexte, je vois bien l'utilité de ce genre de programme. Même pour des projets de 1 mois, on se perd vite entre des grosses specs de fonctionnalités, des grosses spec de tests, et une implémentation des tests.

A mon boulot, mon équipe a développé un framework de test en Python pour faire des tests avec beaucoup de meta-données. Chaque test référence notamment un requirement, ou une référence du plan de test (parfois les deux) plus deux ou trois autres informations utiles.

Du coup, on peut générer un plan de test assez touffu à partir de l'implémentation même. Ce qui est bien, c'est que les deux informations "ce qui est testé" et "le test même" sont au même endroit, donc on a pas le risque que l'implémentation des tests soit moins à jour que le plan de test lui-même.

Avec ton outil, je pourrai prouver que mon plan de test généré à partir de ma suite de test couvre bien toute la spec de test et tous les requirements identifiés.

Et quand le standard arrive 20 ans après l'existence du logiciel, c'est quand même petit de le critiquer.

Excuses ma grande naïveté mais à chaque fois que je vois "on gère tout en RAM", je ne comprends pas. Comment tu fais si on tu as un crash de ton serveur ? Tu as bien une notion de persistance hors-RAM quelque part ?

C'est toujours le reproche numéro 1 que font les ruby-istes à Python: en python on écrit souvent len(toto), type(toto), unicode(toto), etc et ça choque les ruby-istes (et les smalltalk-istes) qui estiment qu'un langage n'est pas objet si on peut pas faire toto.len(), toto.type(), toto.as_unicode().

Le choix a été fait il y au longtemps par Guido, avec l'argument suivant: il estimait que la forme Python était plus lisible et plus facile à comprendre. Cet argument peut faire débat, perso, ça me passe au dessus. En langage courant en dit "je veux la longeur de toto" et "I want the length of toto", ce qui se calque bien sur le choix fait par Guido.

Ce qui me gène par contre, c'est l'argument que à cause de ce choix de syntaxe, Python ne serait pas un langage objet. Où est-il dit que si on applique une fonction à un objet, un langage n'est plus objet ? Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

Est-ce que interdire la fonction main() comme le fait java en fait un langage plus objet qu'un langage où on appelle une fonction main() ?

C'est un besoin extrêmement courant.

Sous Vim, j'aurai tendance à faire une macro vite fait: je me mets au début du premier blabla, je tape qq, je fais ma modif et ma place sur le 2e blabla, et je tape q, puis @q pour répéter sur les lignes suivantes.

Sous SublimeText, je pose le curseur sur le premier bla, je duplique le curseur sur les 6 lignes avec Ctrl+Alt+Down. Ensuite, j'édite mes 6 lignes simultanément, en profitant d'un feedback visuel immédiat.

C'est de moins en moins vrai avec les dernières constructions du langage, mais pendant longtemps, quand tu voyais un programme Python et que tu connaissais le C,C++,Java,VB ou C#, tu comprenais ce que faisais le programme.

mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner.

Je serai curieux de voir ça. Python 2 est globalement rétrocompatible.

Du côté de mon expérience personelle:

• j'ai appris à coder en Python 1.5.2 et j'ai codé longtemps avec un interpréteur 2.2 sans rien connaitre des nouveautés de Python, sans que ça me pète à la gueule
• lors de nos migrations internes au boulot 2.2 -> 2.5 et 2.5 -> 2.7, on a rencontré absolument aucun problème.
• je maintiens un programme qui tourne sur Python 2.5 à 3.4 toutes versions comprises, avec une seule base de code.

Par exemple, None et yield sont des noms de variable valide en Python 2.2.

Là, bon évidemment! Mais tu assignes souvent une valeur à None, même en Python 2.2 ? J'aimerai bien voir un programmer marcher avec None = 1, juste pour rire.

Il reste donc les nouveaux mot-clés: yield , with et probablement un ou deux autres.

• Qt: javascript

Honnêtement, ça m'arrache le c** de dire ça mais je pense que javascript est le meilleur langage de script qui réponde à ces contraintes:

• raisonnablement populaire
• facile à apprendre pour que n'importe qui crache un script vite-fait
• corollaire: ressemble à un langage existant genre C/C++/Java. Exit donc tous les choix en dehors de Python
• portable
• raisonnablement facile à embarquer (Python brille pas ici mais il s'en sort)
• relativement compact (Python, oups… mais il fait des progrès il parait)

Je pense que c'est pour toutes ces raisons que Qt a finalement choisi Javascript bien que ce soit pas un choix évident.

Vraiment, tu devrais regarder de SublimeText. Il a un très gros inconvénient: il est closed source. En dehors de ça, il fait tout ce que tu décris et plus: curseur multiples, édition verticale (si j'ai bien compris), mapping Vim, extensibilité en Python, portable sur le trio Lin/Win/OsX

Il fait des bidouilles qui marchent pas trop mal. Sauf que ce type de bidouille a ses limites. Pour un portage vers KDE en mode composant KPart, on a dépassé ces limites.

Pour l'autre produit phare de Fog Creek, FogBugZ, Joel Spolsky a fait un choix inverse.

• FogBugZ est développé dans un langage maison qui ressemble a du PHP, mais en mieux, avec quelques fonctionnalités sympa.
• ce langage est compilé vers du PHP de base, et tu peux choisir la version cible de ton PHP
• du coup le déploiment d'un FogBugZ en interne dans une entreprise est triviale, la seule dépendance est un PHP de base, sans modules à la con.

Le mode de distribution a donc une influence majeure sur les choix techniques à mettre en place dans l'architecture du logiciel et a fortiori son langage de programmation.

Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème?

mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature.

Oui et non. De fait, le fork va réduire le nombre de lignes de code en s'appuyant sur des lib existantes, en supprimant des fonctionnalités inusitées (la comapbilité old-vi est elle encore une fonctionnalité ?).

Une restructuration de la base de code permettra de séparer mieux les GUI et limitera le mélange des genres.

Après, il ne faut pas se leurrer, Vim reste un gros logiciel. Il y a un langage de script, un moteur de coloration syntaxique, un gestionnaire de terminal, la gestion de macros, de registres, des 5 modes d'éditions différents, de lancer des compilations, des bindings pour différents langages (Python, …).

Tout ça ne va pas disparaitre et va rester coton à maintenir !

Pour l'avoir tenté, lua ne serait pas mon premier choix, même si c'est celui qui a été fait par neovim.

Ce qui est cool, c'est d'avoir un langage de script prêt à l'emploi, documenté, avec même un jit qui existe. Les gros incovénients de lua, c'est:

• le paradigme de programmation est plutôt original par rapport à ce qu'on connait: pas de classes mais une émulation complexe est possible mais va vite être potentiellement foireuse
• pas de compatibilité assurée entre les différentes versions de lua. Et ça, ça fait mal. Il n'est même pas possible d'écrire un programme qui soit à la fois compatible entre lua 5.0 5.1 et 5.2 . Les syntaxes diffèrent de manière incompatibles…

Je l'ai fait, ca s'appelait KVim et ça ne marche pas. Justement à cause de la structure monolithique de Vim. Neovim entend casser cette structure monolithique et permettra si il remplit ses objectifs de faire un KVim fonctionnel et facile à maintenir.