Philippe F a écrit 2204 commentaires

Pour le développement avec Git en particulier. Mercurial avait le bon goût d'être parfaitement fonctionnel sous Windows, sans aucune bidouille à la c** comme git. Sinon, je recommande sourcetree, c'est closed source mais ça marche très bien.

Pour ces histoires de Windows, l'histoire se répète. Il y a quelques années, Gtk a plus ou moins gagné la bataille des GUI préféré pour le dev d'applis sous Linux. Sauf que avec Gtk, Windows est une plate-forme de seconde zone. C'est pas un problème pour une appli qui démarre mais pour toutes les applis très populaires, Windows devient un jour une plate-forme cible et là, le cauchemar commence. Certains persistent (comme Gimp, mais au prix d'un seul développeur, donc d'une grande fragilité de la maintenance) et d'autres laissent tomber pour un choix plus pérenne (Wireshark, Subsurface, GCompris, …).

Pour Git, on est reparti pour un tour. Le support Windows est moyen, Git n'a pas du tout été écrit pour fonctionner sous Windows. Ce qui est donné sous Linux (tout un tas d'outil en ligne de commande) est difficile à avoir sous Windows. Et c'est pas prêt de changer. Mon dernier exemple en date, c'est que si je rajoute git à mon path sous Windows pour travailler sur un projet Git, je peux plus utiliser subversion sur mon autre projet. Git embarque en effet son propre subversion, incompatible avec le mien.

Et contrairement à la bataille Qt/Gtk où Qt a de nouveau ses chances, la bataille Git/Mercurial est perdue depuis longtemps par Mercurial. GitHub ne va a priori jamais rajouter un support Mercurial (tout leur flow est basé sur Git). Même chez Atlassian qui soutenait pas mal Mercurial avec Bitbucket, on laisse tomber Mercurial tranquillement: tous leurs produits sont basés sur Git.

Si tu forkes, c'est une bonne pratique de changer de nom. Si tu fais revivre un logiciel à l'abandon comme dans mon cas, c'est plus délicat. Mais un mail de courtoisie me parait le minimum. Ca m'est déjà arrivé plusieurs fois d'être celui qui reprend un projet et j'ai toujours écrit à l'auteur original, parfois avec succès (allez-y les gars, c'est fait pour), parfois avec une réponse plus mitigée (je vais voir si je peux intégrer tes changements puis finalement rien ne se passe). Mais le fork non annoncé, c'est pas très sympa.

Après, je m'agace peut-être pour rien, le modèle de GitHub est basé sur du fork a tout va, le monsieur n'a pas pris la mesure de tout ce qu'il faisait.

Ils vendent aussi une version installable en entreprise de GitHub.

Je stocke mes mots de passe sous forme de messages cryptés dans un répertoire de ma boite mail. J'ai rarement besoin d'être mobile mais si le besoin s'en faisait sentir, un petit coup de gpg + imap pourrait résoudre le problème.

Comme quoi les vieux trucs, ça marche très bien.

Alors, je me lance, vu que j'ai renoncé à Vim pour SublimeText…

SublimeText, c'est:

• un éditeur qui est beau graphiquement quand on le lance (vim et emacs puent encore le vt100 à plein nez !)

• des tab bien évidemment

• des vues que tu peux organiser selon des layout, genre ficher en haut de l'écran et fichier en bas, ou fichier ds une colonne, fichier ds la 2e colonne, fichier ds la 3e colonne. Sous vim, il faut faire des split à tour de bras pour faire ça il me semble.

• une configuration assez poussée pour tout un tas d'options, qu'on peut facilement éditer en json

• bien sur, une coloration syntaxique pour tous les langages de la terre

• un gestionnaire de package hyper facile à utiliser ( https://packagecontrol.io/ )

• des package pour étendre les fonctionnalités dans tous les sens (3150 package à l'heure où j'écris cette dépèche)

• un mode vim qui tient la route fourni de base

• le support de curseur multiples pour faire des changements multiples dans un fichier (cf la démo sur http://www.sublimetext.com/ , c'est plus simple à utiliser qu'une macro vim et surtout on voit le résultat en direct)

• dispo sur linux, mac, windows

• closed-source

• utilisable gratuitement indéfiniment, il te propose juste d'acheter la licence de temps en temps quand tu sauves (ce que j'ai fait, l'auteur le mérite)

• de la complétion, un peu bof de base, mais étendable à merci. On arrive à compléter du C++ et du Python de façon correcte

• rapide

• écrit en Python et corollaire, étendable en Python, soit un langage plutôt facile à appréhender

• agréable à utiliser

• un mode compilation adapté à tous types de compilateur (l'équivalent de :make dans vim, sauf que là, ça marche de base pour des tests unitaires Python, des erreurs en Lua, du Gcc et j'en passe)

• détection automatique de l'indentation, de l'encodage du fichier, du type de newline du fichier (pour l'indentation, vim ne l'a toujours pas mais vous pouvez utiliser mon "plugin")

• des raccourcis pour faire des opérations simples mais pratiques sur du texte. Par exemple, je me sers souvent de la fonctionnalité pour dupliquer une ligne (oui, c'est plus rapide que yyp), monter ou descendre des lignes

• du code folding

Le curseur multiple, on pourrait dire que c'est la killer feature. Mais même sans ça, c'est un éditeur très très complet, facile à étendre, qui reste pourtant accessible et rapide.

Atom ressemble clairement à une tentative de faire la même chose par un développeur qui maitrise la stack web et qui veut un éditeur open-source. Autant je comprends le 2e point, autant le 1er est un peu bizarre. Cela dit, j'ai vu un debuggeur python construit sur une stack web qui avait l'air de tenir autrement mieux la route que les pauvre GUI qu'on se tape en Python alors pourquoi pas…

En tout cas, vim a du mouron à se faire, entre les SublimeText, Kate, NeoVim et Vile, on trouve des clone qui tiennent la route et qui convertissent des aficionados !

A ce propose, qq'un a déjà utilisé SublimeText 3 et est-ce que ça vaut le coup par rapport au 2 qui marche très très bien ?

La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.

Et toi non-plus. Au fait, tu sais qu'il y a pas que le Larzac, tu peux aussi ouvrir une boucherie porcine en Arabie Saoudite, ou un restaurant de fruits de mer au Tibet, ne te gènes pas pour nous.

Qt dépend très très fortement de son coeur en Qt (avec du QObject, un préprocesseur maison et une boucle d'évènement à la Qt). Ceci le rend très peu généralisable.

Pour donner un exemple concret, une string en Qt, c'est une suite de caractère avec un encodage connu, que tu peux convertir dans d'autre encodages (latin1, utf8, …). En STL, une string, c'est un tableau de caractère dont l'encodage est inconnu et varie d'un système à l'autre, et varie aussi suivant les options du compilateur. Il est donc a priori impossible de convertir une string STL en string Qt (sans apport d'information extérieur).

Dans la couche réseau de Qt, tu trouveras tout un tas d'autres limitations, lié en général au fait que Qt fait des choix explicites alors que la STL a une approche "ouverte" dans laquelle tu peux plugger le choix que tu veux.

Ca ne veut pas dire qu'il n'y a pas d'échange de bon procédés. Quand tu vois des blog de développeurs Qt, tu constates qu'ils passent à la loupe la STL avant de faire leur choix en terme de techno, d'implémentation, etc etc. Et dans l'autre sens, certaines idées intéressante de Qt ont été reprises dans boost sous une forme plus STL: je pense au célèbre mécanisme signal/slot de Qt, qui dépend du préprocésseur de Qt, et était donc inutilisable en contexte boost/STL. L'idée a quand même plu puisque quelques années après la croissance en popularité de Qt, une implémentation en style boost/STL est apparue (template à mort, pas de préprocesseur): http://www.boost.org/doc/libs/1_57_0/doc/html/signals.html .

Je suis supris, on entend plus jamais parlé de progrès sur l'interopérabilité avec les autres bureaux d'environnement. Quid de l'unification de la base mime avec KDE ? Quid du partage du système de notification ? Et il me semble qu'il y a d'autres sujets en cours, non polémiques, qui semblent à l'arrêt…

Gnome aurait-il décidé de poursuivre son chemin seul et négligerai-t-il ses camarades de desktop ?

Vim ? Un demi-mega octet pour le fichier eval.c . J'arrive plus à retrouver des mega-fonctions mais il y en a pléthore !

Et dire que les prochaines centrales électriques qu'on va construire serviront juste à ce que chacun recharge son 33e gadget connecté à la maison.

C'est pas si atypique que ça. Je bosse dans une PME où c'est ce qui vient d'arriver. Après, ne pas être CEO ne veut pas dire qu'il ne dirige pas l'entreprise, il y a des échanges constants. Par contre, il y a un focus plus technique que opérationnel.

Il me semble que c'est aussi ce qu'a fait Steve Jobs chez Apple, faire venir une pointure en CEO. Lequel a fini par dégager Jobs !

Bien évidemment, c'est l'environnement de bureau disponible par défaut qui a été leur critère de choix numéro 1.

Je me relis pour voir:

Autant dire qu'on est dans des développements très spécifiques qui n'affectent pas la majorité des programmes écrits en Python.

Bon, ok, j'en ai fait un peu trop. Il est tellement fréquent de lire CPython c'est de la m**** à cause du GIL que j'ai voulu redonner du poids au fait que CPython marche plutôt pas mal. Mea Culpa !

Et il me parait important de rappeler que le problème du GIL n'est pas un problème générique mais un problème qui affecte des cas précis d'utilisation de Python.

les faiblesses de CPython sont des cas particuliers, alors que justement, dans l'absolu, la latence sur les I/O ou une application monothread sont des cas particuliers.

J'avoue que je comprends pas ta phrase.

Il y a le cas général qui comprend tous les types d'applications possibles avec les threads où on peut dire que Python va s'en sortir dans certains cas et pas dans d'autres. Donc au final, une non réponse.

Ensuite, on peut partitionner l'ensemble des application des applications utilisant des threads en applications IO-Bound et en CPU-Bound. Dans le premier cas, Python s'en sort bien, dans le deuxième pas.

Difficile de savoir si le premier cas couvre une majorité ou une minorité d’application. Surtout que c'est plus par domaine. Dans le calcul scientifique, traitement de données (image, video, statistiques), on est souvent dans du CPU-bound donc le GIL peut poser problème. Dans le domaine des utilitaires, des langage d'intégration, on est plus souvent dans du IO-Bound voir du rien-du-tout-bound (ça marche déjà à la vitesse qu'il faut).

Si CPython a une gestion des threads aussi merdique que les OS libres en 2000 (linux-threads et libc_r sous FreeBSD) et bien c'est la vie. Il faut l'admettre.

Si j'avais voulu nier, je l'aurai même pas rappeler dans la dépêche. Tu pourrais m'en dire plus sur la gestion des threads des années 2000, je ne connais pas mais ça m'interesse….

Je suis surpris d'avoir fait penser que je suis pro-CPython. C'est tout à fait faux. J'ai beaucoup d'espoir dans des implémentations alternatives qui enrichissent l'écosystème.

Je trouve que PyPy est un super projet, tout comme IronPython. Jython, je connais très peu, ce que j'ai indiqué aussi clairement que possible. Unladen Swallow est un projet extraordinaire. Pyston, aujourd'hui, c'est juste une annonce et trois bouts de code.

Par contre, je n'ai pas cherché à masquer les problèmes des différents projets: PyPy ne gère que moyennement les modules d'extensions, IronPython restera un citoyen de 2nde zone dans un écosystème .NET (par rapport à Visual Basic), CPython souffre toujours de son GIL dans des conditions précises, Unladen Swallow est mort, Jython a l'air de souffrir pas mal.

Aujourd'hui, si tu cherches un substitut complet à CPython, il n'y en a pas. C'est un fait objectif.

Maintenant, si tu cherches un substitut à CPython et que ton projet utilise peu de modules d'extensions, PyPy est un très bon choix. Avec un peu de chance, les modules seront compilés ou compilables avec cpyext ou sera facilement interfaçable avec cffi.

De même côté IronPython, si tu cherches un substitut à Visual Basic, tu peux passer ton chemin.

Et Cython, Shedskin, Psyco, etc. J'ai parlé des VM, la page référencée en fin d'article liste de nombreuses autres expérimentations…

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.