Vous avez compris que Python sans virtualenv c’est comme la mer sans les vagues, c’est comme les vagues sans l’écume, c’est comme l’écume sans le sel, c’est comme le sel sans le poivre…

Mais c’est aussi appétissant que les méduses échouées.

Donc pour se faciliter la vie, vous utilisez virtualenvwrapper.

Et bien il y a plus meilleur : pew.

Non content d’avoir un nom cool et court, c’est un progrès non négligeable dans l’ergonomie de notre vie de dresseur de reptiles.

D’abord : pip install pew.

Ensuite, tableau d’équivalence avec virtualenvwrapper :

Vous noterez que les commandes de pew sont plus faciles à retenir, plus cohérentes, et toutes des sous-commandes histoire d’éviter de pourrir son espace de nom.

Autres avantages : pew n’a pas besoin qu’on ajoute un fichier à votre .bashrc pour marcher. Car pew ne source pas un env dans votre shell courant, il ouvre un nouveau shell. Pour sortir de l’env, c’est donc un simple Ctrl + D.

Seulement ça ne s’arrête pas là. Pew possède quelques commandes bonus qui changent bien la vie :

Bon, le seul truc qui manque pour le moment, ce sont les hooks.

Certains l’auront noté, les tampons sont de retour.

J’ai aussi, à la demande d’un lecteur, ajouté un plugin pour permettre aux commentaires d’être écrits en markdown (avec les extensions de github).

Pour obtenir la parité avec le précédent blog, il nous faudra donc restaurer encore quelques easter eggs et améliorer les images sur la page d’accueil, mais c’est presque fini. Comme quoi, une migration, c’est long. Et chiant. Et ingrat.

Bon, j’ai pas fini mon slideshow sur WAMP, donc je vais faire un article sur ça.

iPython notebook, c’est pratique, mais une seule personne peut coder à la fois. Si quelqu’un veut voir les changements, il faut recharger avec F5. A l’heure des Google Doc temps réel, c’est con. Surtout que c’est du ZMQ derrière.

Du coup je me suis lancé dans une expérimentation avec TogetherJS, la lib de Momo pour le travail collaboratif.

Pour lancer le truc, il suffit d’aller dans son dossier de profile iPython et éditer le fichier Javascript vierge fait pour étendre l’outil. Par exemple, sous Ubuntu, mon profile par défaut est dans ~/ipython/profile_default et le fichier à éditer est ./profile_default/static/custom/custom.js.

Dedans on met :

TogetherJSConfig_autoStart = true;
TogetherJSConfig_cloneClicks = false;
TogetherJSConfig_dontShowClicks = true;
$.getScript('https://togetherjs.com/togetherjs-min.js');

Et on est bon. Il faut ouvrir deux browsers différents pour bien tester le truc, par exemple un chrominou et un firefoune. Moi j’ai ouvert deux FF parce que j’ai pleins de profiles dessus.

La frappe est bien synchro, mais malheureusement pas l’affichage du résultat. Y a donc bien un truc intéressant à creuser, mais pour le moment, c’est pas utilisable.

Ensuite, il y a des services Web. SageMathCloud annonce faire cela, mais impossible de s’inscrire, le formulaire ne marche pas. Codebox propose un env complet de dev en ligne, mais l’inscription est temporairement suspendue. Codebunk marche pas mal, est plutôt bien foutu et clair, mais Python 2.7 uniquement, et aucun moyen d’installer une lib, donc adieu scipy ou matplotlib.

Celui qui s’en rapproche le plus est Pythonanywhere : des consoles synchronisées pour toutes les versions de Python, beaucoup de libs préinstallées (dont scipy et matplotlib), un vrai système de fichier sur lequel travailler, du pip a dispo. Et en prime un éditeur de texte pour des fichiers complets, mais qui lui, n’est pas collaboratif. Damn it. Et impossible d’afficher en ligne une image pondue via matplotlib. En plus, on a pas le concept des cellules d’iPython, qui est super pratique.

Bref, il manque vraiment un outil pour faire ce genre de choses.

Depuis quelques jours je suis en discussion avec Tobias de Tavendo. Comme vous avez pu le remarquer avec mes précédents articles sur WAMP et Crossbar :

• Ils sont bons techniquement, et nuls pour expliquer ce qu’ils ont techniqué.
• Cette techno est une techno de rêve pour moi. J’y crois à mort.
• Je suis le seul à avoir pondu des explications décentes sur WAMP et Crossbar. Et ça n’a pas suffit à faire battre un cil.

Bref, ils ont embauché des mecs de haute voltige pour la technique (du genre un contributeur PyPy). Et ils m’ont contacté pour me demander si je n’étais pas chaud pour faire de l’évangélisme, rémunéré, autour de WAMP, Autobahn et Crossbar.

L’idée : écrire des tutos, des articles, améliorer la doc, répondre sur le chan IRC, etc.

J’adore le concept, vu que j’aime leur projet et que je le faisais gratos avant, surtout qu’ils sont pas trop contraignants sur le temps que je vais passer dessus.

Donc voilà le deal : quand je vais pondre des tutos et des articles sur WAMP et Co, je vais d’abord les faire en français ici. Comme ça j’aurai les retours des lecteurs du blog qui pourront, comme d’habitude, me faire part de leurs douces remarques sur à quel point on ne pige rien.

Une fois la prose aiguisée, je traduis et je publie chez Tavendo.

Je disclose donc ici que vous verrez peut-être des prochaines rédactions qui seront attachées à une activité pro. Pas impartial donc. Mais bon, depuis quand je suis impartial ? Javascript c’est de la merde, et je préfère les rousses.

Par saucisse d’honnêteté, je signalerai chaque choucroute concernée avec un lien vers ce post.

Enfin, le contrat est pas signé encore, mais vu que je vais commencer à taffer dessus aujourd’hui, je pense à une première publication demain sous la forme d’un slide show expliquant avec de jolies diapos ce que sont WAMP, Autobahn et Crossbar. À quoi ça sert et ce qu’on peut faire avec.

J’ai lu récemment sur un forum la question “quand utiliser Python ?”. Mais la vérité c’est que Python est un langage globalement bon partout. En fait, on peut presque tout faire en Python car c’est un langage bourré de qualités avec une belle communauté et des libs pour presque tout.

Du coup, je pense qu’il est plus judicieux de se poser la question inverse : quand ne pas utiliser Python ?

Pour le moment, j’évite d’utiliser Python dans les cas suivants :

• L’équipe avec laquelle je travaille est bien meilleure dans un autre langage. Il faut profiter des compétences de chacun au maximum plutôt que privilégier une technologie, c’est plus productif.
• Je reprends du code d’un projet solide, dans un autre langage. Inutile de réécrire quelque chose qui est propre et qui fonctionne.
• Je travaille dans un environnement où d’autres technologies sont mieux intégrées. Par exemple, dans une entreprise avec une forte culture Java, faire les choses dans son coin ne va pas permettre un bon travail d’équipe. Travailler avec une boîte qui a des serveurs qu’ils ne peuvent pas changer et d’autres technos ? Inutile de forcer la main.
• Des technologies plus productives existent pour ce domaine : c’est le cas de l’embarqué, ou des jeux vidéos. Ça ne veut pas dire qu’on ne peut pas en faire en Python. En fait, il y a un fort travail de la communauté pour améliorer cela en ce moment même. Mais difficile de combattre les outils en C/C++ dans ces domaines.
• Je suis pressé, et la solution de facto n’est pas en Python. Par exemple, je veux faire du Web temps réel. Si j’ai le temps, je ferai du Python, car ce n’est pas grave si il me faut aiguiser moi-même quelques outils pour obtenir le résultat désiré. Si par contre j’ai 2 semaines devant moi, je prendrais NodeJS, malgré mon dégoût pour le Javascript, car je suis pragmatique.
• J’ai mesuré mes besoins objectivement, et est évalué que Python ne serait pas assez performant malgré toute les mesures d’optimisation que je sais mettre en œuvre. Dans ce cas, on se tourne vers des solutions plus lourdes mais nativement plus rapides : C, GO, Erlang etc.
• Je vise une plateforme en particulier (Windows, iOS…), je n’ai pas besoin de porter mon code, et je sais qu’utiliser les outils de la boîte qui fait l’OS me donnera de meilleurs résultats. Par exemple si je vise Android uniquement, utiliser leur SDK donnera une app plus fluide et une UI mieux intégrée.

Dans tous les autres cas, Python est un choix excellent.