vim vs ipython: quickfix
J’ai lu avec intéret les 2 posts d’arnaud sur ipython et pour le moment je fais mieux avec vim (et depuis des années, pas avec la version 2012!)
pour le fait de pouvoir manipuler la stdout d’une commande, qx existe en perl et il doit y avoir un truc du meme gout en python:
my @lines = qx(ls); my $i=0; print $i++,": $_" for @lines;
pour %edit … toi quoi vient du monde des IDEs, je pige pas que tu utilises ce truc! j’ai ouvert google, tappé « Eclipse python » et suis tombé là dessus.
maintenant: quand je te disais que vim était tout a fait bien, demonstration:
dpkg -L vim-runtime | grep perl | vim -
que vois-je?
/usr/share/vim/vim71/syntax/perl.vim
syntax highlight
.vimrc: syn on
/usr/share/vim/vim71/indent/perl.vim
/usr/share/vim/vim71/ftplugin/perl.vim
un filetype plugin et indent
.vimrc: filetype plugin indent on
/usr/share/vim/vim71/compiler/perl.vim
un compiler! kesako? et bien a part le debbuger interactif, vim dispose des fonctions minimales d’un IDE:
- la commande :make permet de lancer la commande externe make
- la sortie d’erreur est utilisé par vim pour créer une liste d’erreurs, la liste des fichiers et des lignes ou ces erreurs se sont produites.
- apres execution, vim se met sur la premiere erreur
- :clist te permet d’afficher la liste des erreurs, tu tappes le numero d’erreur pour y acceder
ouais mais tu vas pas créer un makefile pour un script python? right! c’est pourquoi tu peux choisir la commande qui sera executée a la place de make grace a makeprg. La chose est que le symbole % est expand comme le nom du fichier courant.
et puis la clist, comment elle est générée? réponse: vim utilise la variable errorformat qui contient une liste de motifs et des instructions pour savoir quoi en faire. C’est avec cette variable que vim traite la stderr.
le fichier compiler se limite en général a déclarer correctement ces deux variables. ensuite, tu appelles la commande compiler (soit directement depuis le mode commande de vim, soit en ajoutant dans ~/.vim/ftplugin/perl.vim)
alors que ces fichiers sont tres riches pour perl, tout ou presque reste a faire pour python (bonne chance pour le errorformat).
autre variable intéressante: autowrite qui enregistre automatiquement avant :make.
allez, exercice:
vim jefaispi.py
:set aw makeprg=python\ %
# edit, edit, edit
:make
# edit, edit, edit
:make
ZZ
sauf que ca va vite etre chiant de tapper setmakeprg=… a chaque fois que je code et je n’ai pas envie de remplir un par un les fichiers ~/.vim/ftplugin/* avec l’interpreteur qui va bien … d’autant que tu utilises de temps en temps des options de l’interpreteur (perso en perl: -wc, -T -I …) … en plus c’est presque aussi chiant de tapper :make que de relancer …
et la, marco te sors son vimrc .. enfin .. un petit bout:
" don't need to write before :make set aw " :MP perl % " to set perl as 'makeprg' command -nargs=* MP exec 'set mp=' . escape(<q-args>,' ') nnoremap ,c :make<cr>
ok … on refait la meme chose qu’avant:
vim jefaispi.py
:MP python %
# edit, edit, edit
,c
# edit, edit, edit
,c
ZZ
Related posts:
Themocracy
Putain payes ta mauvaise foie
Faudrait que tu l’essayes car la je suis pas convaincu que tu ai compris comment ça fonctionnes ….
En effet, je me suis cassé le cul à faire des posts structurés, bien construits, truffés d’exemple explicites et là j’ai droit à un gros pâté en retour. Moi qui ne suis certainement pas aussi à l’aise que toi avec Vim, j’avoue que je ne comprends pas tout, surtout quand tu mélanges Perl, .vimrc et commandes Vim (le post suivant est encore pire).
Premier point :
Je n’ai pas voulu comparé IPython à quoi que ce soit. Vim est puissant, on le sait tous. Mais là je parle d’un interpréteur de commande, pas d’un IDE.
Deuxième point :
Le gros avantage de IPython, c’est que tu as tout en installant UN paquet et que tu n’as aucun fichier de conf à te taper pour que ça fonctionne comme tu veux
Troisième point :
Il t’a fallu combien d’années pour avoir un .vimrc comme cela… Ce n’est pas donné à tout le monde de savoir comment configurer son vim comme tu le fait. TU as réussi à avoir un Vim performant à souhait, je ne pense pas que ce soit le cas du commun des mortels qui verront la lumière en IPython, au contraire du côté obscur d’un .vimrc
Quatrième point :
[quote]
toi quoi vient du monde des IDEs, je pige pas que tu utilises ce truc! j’ai ouvert google, tappé « Eclipse python » et suis tombé là dessus.
[/quote]
J’ai testé… c’est mauvais, très mauvais et ça n’arrive pas à la cheville de ce qu’Eclipse est pour Java. Si j’utilise un IDE, c’est que pour coder en Java, vu la verbosité extrême du langage, tu peux que te permettre un IDE solide… Un IDE bien plus puissant pour Python est Komodo… Mauvaise utilisation de Google Marc !
Cinquième point :
[quote]
pour le fait de pouvoir manipuler la stdout d’une commande, qx existe en perl
[/quote]
En Python, tu as plusieurs solutions :
[code]
status, stdout = commands.getstatusoutput('ls')
[/code]
Qui renvoie le retour sous forme d’un chaine de caractère et le statut
[code]
os.popen('ls')
[/code]
Qui renvoie un descripteur de fichier contenant le résultat de ta commande
Seulement si tu as bien lu mon post, ce que fait IPython est bien mieux. Ton retour de commande devient un objet inclu dans l’API Ipython qui est manipulable son forme de chaine de caractère, de liste … et auquel s’ajoute d’autres fonctions (je ne m’étends pas puisque ça sert à rien)
[code]
Type: type
Base Class:
String Form:
Namespace: Interactive
File: /var/lib/python-support/python2.5/IPython/genutils.py
Docstring:
List derivative with a special access attributes.
These are normal lists, but with the special attributes:
.l (or .list) : value as list (the list itself).
.n (or .nlstr): value as a string, joined on newlines.
.s (or .spstr): value as a string, joined on spaces.
.p (or .paths): list of path objects
Any values which require transformations are computed only once and
cached.
[/code]
kyusan, troll sensei!
Le fait est que contrairement a toi, je teste sans préjugés. Ce que *je* ressors de ces derniers jours:
- soit vous méconnaissez python, soit je continue a croire que python est inférieur a perl sur les points qui me sont chers.
- les seuls avantages de python semblent etre en fait dans les outils périphériques: rst vs pod, intégration des tests unitaires dans les docstrings, ipython et la complétion … bref: le jour ou un méga-module perl sort pour éclipse, python se retrouvera a poil!
Je continue a vouloir progresser en python parceque c’est un langage d’extension de plus en plus courant et que je n’ai pas envie, si il m’est nécessaire de patcher qqchose, de faire du python comme les pythonneux font du perl. Toutefois, je n’ai nullement l’intension d’utiliser python comme langage de developpement … encore moins apres cette discution qu’avant! (la prochaine fois que tu me dis que je suis obtus, je te demanderais de lire ce post 400x)
Une chose m’enerve .. et la nous ne sommes plus dans le langage mais dans l’écosysteme.
- je veux des tips python, on me répond « perl c’est de la merde » (je ne vise pas forcement kyusan: c’est un comportement général du monde python). Meme si Arnaud a dit beaucoup de conneries dans son post trollesque, c’est bien le plus ouvert des pythonneux que je connaisse!
- tout ce que le pythoneux aime dans python existe en perl (j’ai envie de dire: en mieux), tout ce que le pythonneux ne comprend pas est « loufoque » (c’est un peu comme dire « moi je lis oui-oui magazine parceque linux mag c’est loufoque »).
- le pythonneux a tendance a balancer des trucs sans vraiment savoir … ca n’est pas la premiere fois qu’on m’affirme de facon péremptoire qu’il n’y a pas d’objets en perl ou que l’oo en perl est assez récente alors que ca date du millénaire dernier.
- le pythonneux n’est pas curieux: dans une discution comme nous en avons, le but pour lui n’est pas de comprendre ce qu’il y a de bien chez l’autre mais plutot de continuer a s’autopersuader qu’il a raison. Dans un sens, on retrouve ici un trait du langage que je deteste (le « en perl j’ai le choix, en python j’ai tord »).
je continue a penser, donc, que le meilleur énnemi du python est le pythonneux …
Encore un post dont ni le contenu ni la réponse n’auront servi a qqchose … je vais finir par ne plus te lire
sinon: t’as pas un truc *bien* a me montrer en python?
Par rapport a Ipython vs vim: je vous propose qu’on se fasse une bouffe ou un resto au plus vite! jeudi ? vous pouvez venir a la maison jeudi soir?
Mais ce qui m’énerve au plus au point, ce que quoi que je mette comme Tips ou comme explications sur Python, j’aurais le droit à un :
» Arnaud y’a mieux, t’es bien gentil » … surtout quand on va a pas au bout de mon post.
Dans tous mes post Python, j’ai exploré un truc du monde Python sans jamais dévié sur autre chose.
[quote]
« perl c’est de la merde »
[/quote]
Voilà une phrase que je n’ai pas dite une seule fois depuis mon [quote]comm trollesque plein de conneries…[/quote]
[quote]Mais ce qui m’énerve au plus au point, ce que quoi que je mette comme Tips ou comme explications sur Python, j’aurais le droit à un » Arnaud y’a mieux, t’es bien gentil »[/quote]
Il est toujours tres difficile de faire passer un ton dans un message, alors je résume:
Il n’y a aucune critique de tes pratiques dans mes posts: te lire me permet de savoir comment vous pratiquez et c’est instructif parceque le jour ou je discurerais avec vous d’un point particulier par exemple, je ne serais par largué quand vous degainerez la ipython.
Il me semblait que tu partageais mon envie d’en savoir plus sur les pratiques des autres. Il m’a donc semblé de bon ton, donc, de t’expliquer comment je m’etais passé d’edit (l’avantage est que je procede de la meme facon qqsoit le langage).
C’etait une facon pour moi de te remercier et non de t’enerver. Maintenant, si le fait de partager des astuces t’enerve, je m’en abstiendrais désormais …
[quote] … surtout quand on va a pas au bout de mon post. [/quote]
tu peux préciser ?
[quote]Dans tous mes post Python, j’ai exploré un truc du monde Python sans jamais dévié sur autre chose.[/quote]
dans tous mes posts vim, je me suis bien gardé d’attaquer ipython!
[quote]« perl c’est de la merde » Voilà une phrase que je n’ai pas dite une seule fois depuis mon[/quote]
je répondais a kuysan (cf. son astuce numero 1) et je suis désolé que tu prennes pour toi un resenti général dont tu es la seule exception comme je l’ai deja dis!
[quote]comm trollesque plein de conneries…[/quote]
Je n’ai pas répondu parceque je me disais que nous devrions nous concentrer sur l’échange et non sur le troll. Toi tu es parti sur l’échange (je t’en remercie grandement) et kuysan sur le troll.
Toutefois, ton premier post est en effet truffé de préjugés et d’erreurs factuelles (j’aurais du me garder du mot connerie pour lequel je te prie de m’excuser). Si tu le souhaites, je peux les reprendre 1 par 1 avec toi mais ca m’ennuierait vraiment (je préfère lire tes tips sur python).
je continue a trouver tes posts intéressants et instructifs et tu continues a trouver les miens enervants.
A nouveau, il me vient de nombreuses questions et des tips que j’aurais envie de partager avec toi.
si c’est pour que tu y voies une nouvelle attaque … je jette l’éponge
Il n’empeche qu’on peut quand meme se faire une bouffe jeudi si ca vous branche. On parlera ni de perl, ni de python, voila tout (j’ai des nouveaux wiskos a vous faire essayer si vous me promettez de pas lancer un troll sur les blended contre single malt)
Comme tu dis, il est difficile de faire passer un ton ou une humeur dans un message. Je veux des tips oui j’en veux ! C’est pas la question.
J’aimerais juste que tes posts soient un petit peu plus lisibles et structurés. Je peux te dire qu’il faut que je me concentre sévère pour certains de tes posts.
Aère tes posts, donne des exemples précis « commandes –> sortie de données ». C’est beaucoup plus parlant. Parce que copier du code et l’exécuter sur ma machine pour savoir ce que ça fait quand je comprends pas devient vite rébarbatif.
Ce que je ne veux pas non plus, c’est que ça devienne une compét’ car c’est pas intéressant.
Mise au point
Le mot « énervé » venait du fait que ton post n’était pas fluide. J’en critiquais pas du tout sa qualité. Après on a le droit d’en critiquer son contenu sans tomber dans le troll, right Sir ?
La phrase « Il est bien gentil Arnaud » c’était pour l’esprit de compèt’ dont je parlais plus haut…
pour le reste I’m Fuck’in In !!!
Sinon il y aura encore quelques tips IPython.
Pour les décorateurs qui est un truc que je commence à explorer, Jérémy pourra mieux t’en parler
En tout cas pas de troll pour moi sur les whisky… j’y connais rien… ou alors je joues la mauvaise foi ?? Tu veux ?
ça devient n’importe quoi.
tu nous dis que Vim est mieux que IPython, alors que ça ne fait pas la même chose !
« Ouais amarok ça pue, k3b c’est bien mieux » pour parodier.
Après que Perl est mieux que Python je m’en cogne, c’est toi qui tiens absolument à le prouver en donnant des exemples qui ratent leur cible (genre je te file un bout de code Perl qui ne fait pas la même chose que le bout de code Python donné, je te compare Vim à IPython et etc …).
Tu t’es tellement plonger dans Vim et Perl que devoir avoir un fichier vimrc de 200 lignes te choque plus, que devoir avoir un backend de 5ans de perl pour relire du code n’est pas gênant.
ça me fait une belle jambe de devoir rajouter des lignes dans le .vimrc pour avoir un truc qui essaye vaguement de faire la même chose que Ipython, alors que j’ai juste a lancer IPython (et sans avoir du faire aucune conf) pour avoir un truc bien plus puissant que le sera Vim dans ce domaine (beh oui Vim est un éditeur jusqu’à la preuve du contraire qui peut s’approcher d’un IDE …).
Pour que tu sois toujours à côté de la plaque avec Ipython, je soupçonne que tu t’ai même pas donner la peine de l’installer et de jouer avec …
Alors bon oui on peut tester du code avec Vim en le tapant et etc, mais ça demande bien plus de manipulations et c’est moins rapide. Pourquoi j’utiliserai un soft qui m’oblige à utiliser 10 raccourcis différents alors que je peux le faire plus naturellement avec IPython …
J’ai vraiment l’impression que tu as abandonné le principe KISS loin derrière toi.
Et pour faire simple Perl me gonfle rien que pour sa syntaxe objet, qui me suffit amplement à choisir un autre langage … et comme on l’a déjà dit, si je dois galérer à comprendre du code, je préféré que ça soit sur la compréhension de l’algo qu’un tirage de nouille syntaxique juste pour se faire plaisir entre guru de Perl.
Alors tu va peux être nous ressortir que Perl 6 arrive et etc, mais comme il est dit, il n’est pas encore la, et c’est aujourd’hui que je veux produire des trucs.
A mon avis le soucis de toute cette conversation, est qu’on a pas la même approche des langages informatiques, pour nous, il doit nous permettre d’être productif, vite appris pour qu’on puisse y faire abstraction afin de se concentrer sur la conception, que le code doit pouvoir être repris facilement par quelqu’un d’autre et etc. Alors que toi (enfin j’en ai l’impression), le plus important est de raccourci le code de 2 lignes pour en écrire le moins quitte à ce que ça soit illisible 6 mois après.
Perso, je suis adepte de la philosophie KISS, et Python correspond à ceci, le langage est simple mais te limite pas dans les possibilités, regarde ce que font des personnes comme le gars de Biologeek, ou Victor Stinner et sa bibliothèque Hachoir.
Python te permet :
– te faire du travail de bas niveaux (hachoir)
– étendre des logiciels (plasmoids, gimp, blender)
– faire des applis web (la communauté web perl est bien fine par rapport à celle de Django par exemple)
– des clients en dur (pyqt et etc)
– faire du calcul scientifique (numpy)
– des scripts systèmes (cf google)
– de maquetter des applis avant de les passer en C++
– de troller sur tinybox
Alors oui, c’est l’écosystème, mais l’écosystème est aussi important que le langage lui même, Ruby est peut être élégant mais jamais (a l’heure actuelle), je ferai des choses aussi facilement qu’avec Python (d’ailleurs pourquoi Ruby tarde tant à percer ?).
Puis faudrait que t’arrêtes avec ton trip de la communauté Python, et tes généralités à deux balles. Essayes de comprendre, que la plupart des personnes s’en cogne d’avoir un raccourci syntaxique pour gagner 2 lignes dans du code si ça le rend moins lisible (et que ça n’apportes pas forcement quelque chose niveau performance).
ça me fait penser aux trolls entre photographe avec Canon, Nikon et etc … au final on s’en cogne avec quels appareils la photo à était prise, à partir du moment qu’elle est belle. Je ferai même un // avec les appareils photos, je m’en fous des automatismes ou des trucs qui sont censés me faire gagner du temps, je préfère un appareil simple, que je maitrise et me donne ce que je veux à la fin (et en ça Python répond parfaitement à mes besoins).