Bonjour à tous,

De plus en en plus de sujets concernant les IDEs pour python sont lancés. C'est pour éviter cela et pour faciliter le choix d'un IDE que j'ai crée ce topic ayant pour objectif de comparer objectivement les principaux environnement de développement intégré.
J'éditerai ce soir ou demain avec un tableau permettant de résumer la plupart des caractéristiques qui fait qu'on choisit (ou pas) un IDE, en attendant je vous propose de présenter celui que vous utilisez

Merci à vous,

Ils sont déjà dans la doc

Effectivement mais c'est peu précis, et il n'y est même pas fait mention de Geany. De plus rien ne vaut un avis pour être sur de son choix

Personnellement, j'utilise Stani's python editor. Il est disponible sur linux ( apt-get install spe ). C'est un éditeur très complet, il intègre un débugger ( winpdb de mémoire ) , il permet de visualiser la documentation des modules utilisés. La coloration syntaxique et l'autocomplétion sont très performantes et le programme très stable ( 0 plantage en 6 mois d'utilisation ). Bref, je vous le recommande !

Citation : Malikemal

Effectivement mais c'est peu précis, et il n'y est même pas fait mention de Geany. De plus rien ne vaut un avis pour être sur de son choix

Tu mélanges torchons et serviettes. Tu crées un topic pour parler d'IDE Python, et tu nous sors Geany qui est un éditeur de texte, qui possède peut être de très bon plugins pour développer en python, ça je n'en sais rien, mais qui reste un éditeur de texte.

Geany a tout de même quelques fonctionnalités assez intéressentes qui fait qu'on peut le considérer comme un IDE, certes pas aussi puissant qu'un autre mais tout de même
Bon si ça intéresse personne ...

Essaye Eclipse avec PyDev

Bonjour,

J'utilise Eclipse + pydev pour les développements Python depuis plusieurs années. J'ai essayé d'autres outils de développement (y compris komodo), mais je suis toujours revenu à Eclipse.

Pydev est un plugin qui s'installe à partir d'Eclipse en donnant son adresse (http://pydev.org/updates).

En dehors des fonctionnalités classiques d'un bon outil de développement (coloration, complétion (y compris avec PyQt4), debugging, console, encodages, exécution, etc...), je l'apprécie particulièrement pour les points suivants:

- existe à l'identique (il suffit d'avoir java) sous Windows, Linux et Mac OS X.

- permet de définir des workspaces avec: répertoire disque regroupant les projets, encodage d'édition, fin de ligne, et interpréteur Python.

- si on a en même temps Python 2.x et Python 3.x, permet de passer de l'un à l'autre par un simple switch entre les workspaces.

- avec un workspace donné, tous les projets sont dans la colonne de gauche, ce qui veut dire qu'on a un accès immédiat à tous les projets, et qu'on peut donc copier/coller facilement des parties de codes réutilisables d'un projet à l'autre (gros gain de temps et d'effort). On peut avoir une politique de création de bibliothèques de modules ou de codes "modèle" pour accélérer et fiabiliser les développements.

- les fichiers py ouverts sont au milieu dans l'éditeur par onglets (autant qu'on veut). On peut à volonté dérouler ou enrouler le code des fonctions, classes et méthodes.

- la structure complète du fichier affiché se trouve dans la colonne de droite (fonctions, classes, méthodes, variables). On peut donc facilement naviguer dans un fichier long en cliquant sur la fonction demandée qui déclenche son affichage dans l'éditeur. On peut même afficher la structure dans l'ordre alphabétique pour accéder rapidement à une fonction dont on connait le nom.

Etc... Je suis très loin d'exploiter toutes les fonctionnalités disponibles.

Eclipse est souvent considéré comme une usine à gaz, mais les PC actuels supportent très bien et ça marche tout seul, même pour des petits développements. Grâce à l'accès facile à tous les projets, j'avance comme une "roue à cliquet": ce que j'ai déjà fait accélère les projets suivants.

Personnellement, j'utilise le simple éditeur gedit couplé avec la console pour mes tests.

Pas de complétion, j'aime pas ça, juste les couleurs (coloration syntaxique) pour égayer ma vie et la doc python.

J'ai testé pas mal d'IDE, et le seul si j'avais le temps d'apprendre plus, serait vim, car si on le maîtrise bien on pourrait aller très vite dans le développement.

Citation : fred1599

Personnellement, j'utilise le simple éditeur gedit couplé avec la console pour mes tests.

Pas de complétion, j'aime pas ça, juste les couleurs (coloration syntaxique) pour égayer ma vie et la doc python.

J'ai testé pas mal d'IDE, et le seul si j'avais le temps d'apprendre plus, serait vim, car si on le maîtrise bien on pourrait aller très vite dans le développement.

Un gros +1 pour fred1599. Idem pour moi...

Personnellement j'utilise Vim dans une console (en gros, un screen avec un buffer faisant tourner Vim et d'autres pour une console Python, ou des shells pour faire des tests).

En plus d'être un éditeur de texte extrêmement puissant (avec des tonnes de commandes taillées pour faire des trucs compliqués en peu de temps), il dispose de toutes les options qui vont bien (auto-indentation, coloration, folding) nativement pour Python... Et pour les autres langages dans lesquels je dois développer.

Après, il est possible d'y adjoindre des plugins permettant de gérer l'auto-complétion, l'ouverture d'un cadre avec la doc sur simple pression d'une touche, le parcours de l'arborescence des fichiers de façon "graphique", la gestion de tags pour sauter d'un appel de fonction à sa définition, etc. mais je remarque que je les utilise de moins en moins, à la longue.

Au final, je me retrouve surtout avec un environnement perso composé de screen + Vim + shells pratiquement sans ajout de conf supplémentaire (donc TRÈS rapide à porter d'une machine à une autre : il n'y a que 2 packages à installer sur un linux standard, + un ou deux fichiers de config à recopier), auquel je peux accéder à distance via SSH si nécessaire, et qui comble tous mes besoins.

Il faut un certain temps d'apprentissage pour être à l'aise dans ce genre d'environnement, cela dit. Le bénéfice que j'en tire est surtout que c'est un environnement très portable qui se compose de l'essentiel (pas de gadgets superflus), qui s'adapte parfaitement à n'importe quel langage de programmation, et qui n'a même pas besoin de serveur graphique pour tourner (serveur graphique qui ne m'apporterait absolument rien de plus, en termes d'ergonomie, que ce que j'ai déjà).

Citation : nohar

Personnellement j'utilise Vim dans une console (en gros, un screen avec un buffer faisant tourner Vim et d'autres pour une console Python, ou des shells pour faire des tests).

En plus d'être un éditeur de texte extrêmement puissant (avec des tonnes de commandes taillées pour faire des trucs compliqués en peu de temps), il dispose de toutes les options qui vont bien (auto-indentation, coloration, folding) nativement pour Python... Et pour les autres langages dans lesquels je dois développer.

Après, il est possible d'y adjoindre des plugins permettant de gérer l'auto-complétion, l'ouverture d'un cadre avec la doc sur simple pression d'une touche, le parcours de l'arborescence des fichiers de façon "graphique", la gestion de tags pour sauter d'un appel de fonction à sa définition, etc. mais je remarque que je les utilise de moins en moins, à la longue.

Au final, je me retrouve surtout avec un environnement perso composé de screen + Vim + shells pratiquement sans ajout de conf supplémentaire (donc TRÈS rapide à porter d'une machine à une autre : il n'y a que 2 packages à installer sur un linux standard, + un ou deux fichiers de config à recopier), auquel je peux accéder à distance via SSH si nécessaire, et qui comble tous mes besoins.

Il faut un certain temps d'apprentissage pour être à l'aise dans ce genre d'environnement, cela dit. Le bénéfice que j'en tire est surtout que c'est un environnement très portable qui se compose de l'essentiel (pas de gadgets superflus), qui s'adapte parfaitement à n'importe quel langage de programmation, et qui n'a même pas besoin de serveur graphique pour tourner (serveur graphique qui ne m'apporterait absolument rien de plus, en termes d'ergonomie, que ce que j'ai déjà).

[Troll Vérité absolue]
emacs emacs emacs emacs emacs emacs...
[Troll Vérité absolue]

Plus sérieusement, si on sort du cadre de l'IDE, Emacs, pour à peu près les mêmes raisons que vim : Tabulation automatique (très bien gérée, contrairement à d'autres éditeur), Coloration, Auto-Complétition, Console Python intégré, etc... Et pareil que Vim un certains temps d'apprentissage.

Après il faut savoir abandonné le coté graphique (bouton, tout ça... ) pour passer sur (quasi) uniquement que des raccourcis claviers sinon il n'y a aucune utilité (la même que pour Vim).

Edit de Fayden : Ceci n'a pas été édité

PS: Il m'arrive souvent d'utiliser IDLE sur Windows, mais quand-même : dans ces moments là, j'ai honte...

Je pense que sous Linux, passer à Vim ou Emacs (je ne suis pas sectaire, les gens ont le droit de se tromper) devient rapidement une nécessité si on veut rester efficace.

Le simple fait que ces éditeurs s'utilisent en console permet de se plonger dans l'usage du shell pour tout, donc par extension de commencer à mieux comprendre son système, donc de faire des choix plus éclairés, donc plus efficaces, donc se rendre compte que le shell est vraiment inégalable, donc qu'il est vraiment bon de l'utiliser, etc. Bref, c'est le cercle vertueux de la montée de compétences, quoi.

Ce qui pourrai être intéressant (je pense) c'est de savoir à partir quand il serait préférable d'utiliser ce genre d'IDE (Vim, Emac) pour programmer aisément.

Faut il avoir quelques compétences dans le shell ou bien mieux vaut il se pencher là dessus lorsque l'on débute ? (Quant est ce que cette utilisation serait judicieuse en terme de productivité ?)

Citation : realmagma

Ce qui pourrai être intéressant (je pense) c'est de savoir à partir quand il serait préférable d'utiliser ce genre d'IDE (Vim, Emac) pour programmer aisément.

Faut il avoir quelques compétences dans le shell ou bien mieux vaut il se pencher là dessus lorsque l'on débute ? (Quant est ce que cette utilisation serait judicieuse en terme de productivité ?)

Il n'y a aucune connaissance préalable pour commencer à les utiliser (la preuve, le tuto Linux de ce site en parle !). C'est simplement qu'il faut se discipliner pour prendre l'habitude dès le départ. Un bon moyen est de prendre ça comme un jeu : si tu n'es pas en train de coder un truc avec une deadline de malade, essaye de le faire bien, en lisant la doc chaque fois que tu veux faire un truc (genre déplacer 5 lignes, ou un bloc, ou répéter 150 fois la même action, ou faire un chercher/remplacer) que tu ne sais pas encore faire, et en t'efforçant de le réaliser à-la-Vim ou à-la-Emacs. Les réflexes viennent ensuite très vite.

Pour ce qui est du shell, c'est aussi une question de culture générale et de réflexes : si tu veux faire une tâche donnée (déterminer ce que contient un fichier ? compter le nombre de lignes de code de tel projet ? connecter ton PC à un réseau via ethernet, changer d'IP, de route par défaut, etc.), lance-toi le défi de trouver comment faire ça en une seule ligne de commande : non seulement t'auras appris à utiliser ton shell, mais en plus il y a des chances pour que tu comprennes mieux comment ça fonctionne derrière ! Ou bien pose la question sur un forum (quitte à te faire répondre RTFM : on a le droit de ne pas connaître telle ou telle commande du shell, c'est comme ça qu'on apprend).

À la longue, ça devient une seconde nature et ça vaut vraiment le coup, seulement il faut se donner le temps que ça rentre.

PS : Et même après des années, on ne finit pas de découvrir de nouveaux trucs.

Bonjour,

Je vais contredire, mais ce n'est pas pour le plaisir de le faire, c'est pour que les lecteurs aient plusieurs visions de l'utilisation de Linux.

On peut effectivement trouver de l'intérêt à apprendre la "machinerie" Linux en bidouillant avec la console (je l'ai fait pendant plusieurs années). Celle-ci est très puissante, et on peut faire avec des choses étonnantes. Mais le serveur X graphique existe maintenant depuis 25 ans, et il serait temps de s'en servir! La console, c'est l'Unix des années 70, et on s'en sert uniquement quand c'est nécessaire: pour modifier l'OS (recompiler le noyau pour intégrer un nouveau driver), pour des tâches d'administration (installer un nouveau logiciel par compilation), pour créer et administrer un serveur web (qui doit être sans graphique), ou pour apprendre les "tripes" de l'OS pendant un certain temps.

Actuellement, on peut se servir couramment de Linux comme on se sert de Windows ou de Mac OS X: avec graphiques. Sous ces 2 autres OS, on ne dit pas aux clients qu'ils doivent apprendre avec la console en mode caractères. D'ailleurs, il y a peut-être pas mal de clients de Mac OS X qui en savent pas qu'il y a une console, et que leur petite merveille a un noyaux BSD petit cousin de Linux...

Bref, comme je suis pour une plus grande diffusion de Linux, je préfère promouvoir son utilisation en mode graphique! Y compris pour les développements de logiciels.

Citation : tyrtamos

Bref, comme je suis pour une plus grande diffusion de Linux, je préfère promouvoir son utilisation en mode graphique! Y compris pour les développements de logiciels.

Et moi je préfère ne rien promouvoir, et me contenter de constater les faits : un développeur n'est pas un "client", et le fait que X existe depuis 25 ans me semble probablement la raison la plus absurde pour passer à côté d'éditeurs puissants, et qui ont fait leurs preuves et été raffinés depuis plus de 20 ans (34 ans exactement si on considère Vi) comme Vim ou Emacs, éditeurs qui ont AUSSI leurs pendants graphiques, au passage.

Sauf que, c'est pas pour troller, mais je constate que dans mon utilisation quotidienne, VNC n'a ni la souplesse, ni la puissance de SSH, et qu'il n'y a aucune solution native et intuitive pour afficher dans une fenêtre le contenu d'un fichier de log en même temps qu'il est rempli (comme le fait parfaitement less +F, qui est probablement l'une des commandes que j'utilise le plus souvent quand je développe). Je pourrais te sortir encore une liste longue comme le bras de choses que X ne permet pas de faire simplement alors qu'elles sont triviales dans un shell, et qu'il ne serait même pas souhaitable de pouvoir faire de façon graphique (à moins de vouloir multiplier à outrance les petits clicodromes superflus).

Encore une fois, un développeur, a fortiori un informaticien, n'est pas un end-user comme un autre. Il n'a ni les mêmes besoins, ni les mêmes attentes de son outil qu'un utilisateur lambda : que Mme Michu utilise Ubuntu avec Unity et s'y retrouve très bien pour lire ses mails, grand bien lui en fasse (d'ailleurs, je ne suis pas non plus masochiste, j'utilise un client thunderbird graphique avec enigmail pour mon courrier, et rien ne remplace Gimp ou Chromium à mes yeux), mais ça ne fait pas partie de ses besoins de monter un sshfs en 5 secondes, ou de corriger en série un fichier de conf sur 200 serveurs à la fois, ou de débugger un script faisant office de serveur sur une machine distante, pour le confort de faire les tests directement, en même temps qu'elle patche le client en local. Moi, c'est mon quotidien.

Ton utilisation d'informaticien ne me dérange pas: je voulais simplement qu'une autre utilisation de Linux soit décrite ici. Ce n'est pas "contre" c'est "en plus".

Tout ce que tu décris, je le connais bien, mais tout le monde n'est pas dans le même contexte.

Et les choses évoluent! De très nombreuses tâches d'administration de Linux peuvent se faire maintenant en graphique: gestion de paquets, configuration réseau, installation d'une imprimante, etc... Je travaille couramment avec les 3 OS Windows Linus et Mac OS X, et je peux accéder en mode graphique à distance à n'importe lequel des 3 à partir de n'importe lequel des 3 grâce à teamviewer (beaucoup plus performant que VNC).

De nos jours, les PC Windows sont capables de porter un ou plusieurs Linux en virtuel - en mode graphique - grâce à VirtualBox (par exemple). Aussi facilement que j'ai installé Windows 8 en virtuel pour l'essayer (=je déteste).

Le fait que nous ne soyons pas d'accord n'est pas grave. Au moins nos 2 avis auront été exprimés.

Effectivement, nous serons tous d'accord pour dire que le shell est beaucoup plus puissant. Mais, pour un membre du Sdz, qui n'est vraisemblablement pas un professionnel (prenons large, 80% des inscrits au moins) ne serait-ce pas plus simple et plus agréable (faut le dire c'est blasant quand on commence de voir un écran noir ...) d'utiliser un IDE graphique ? Surtout que ce que l'on fait c'est pour le plaisir, on est pas spécialement pressé et donc pas forcé d'optimiser notre temps dédié au développement.
Après je ne dis pas qu'il faut forcément jeter le shell quand on est pas pro, mais que dire "Vim est le meilleur" (je ne dis pas que tu l'a dit nohar ) est vrai dans un contexte donné, et encore.

Ouais, enfin les membres du SDZ sont de base des gens qui développent (du moins sur ce forum), et je ne vois pas en quoi le fait d'être un pro ou non devrait influer sur le fait d'utiliser des outils de qualité, reconnus encore aujourd'hui depuis des décennies, ou pas. Je ne fais pas de prosélytisme, simplement il ne s'agit pas que d'une optimisation du temps de développement par professionnalisme : il s'agit avant tout de confort, d'adaptabilité et de pragmatisme. Il y a aussi le fait que plus on sait être efficace avec le strict nécessaire, plus on est rapidement à l'aise pour bosser avec de nouveaux langages ou de nouvelles technos dans des environnements variés.

Typiquement, je trouve que l'on donne de l'importance trop longtemps aux features user-friendly de Linux, et qu'on n'insiste finalement pas assez sur le fait que multiplier les outils revient à multiplier aussi les dépendances : le jour où tu veux compiler un projet sous forme de bibliothèques en C ou C++, ou que tu veux utiliser une bibliothèque qui n'est pas accessible avec dpkg et n'a aucune documentation pour t'expliquer pas à pas comment utiliser un .so, t'es bien emmerdé si tu utilises Code::Blocks et que tu n'as jamais utilisé ton compilo au moins une fois en ligne de commandes (pour découvrir ensuite l'horreur des makefiles, pour découvrir ensuite le bonheur de CMake), pour comprendre comment ça fonctionne derrière. Le jour où ta JVM est pétée et que t'as pas le temps/la flemme de la réparer parce que tu as plein d'idées pour ton projet perso en cours, tu fais comment pour checkouter ton projet et faire des merges sans le plugin SVN/Git/whatever pour Eclipse qui va bien ? Si tu développes en Python, C et Perl et que tu édites en même temps des fichiers de config et des fichiers XML, et que tu comptes essayer/utiliser encore d'autres langages à côté ponctuellement au besoin, tu multiplies les éditeurs et IDE pour chaque langage ? Le jour où tu développes un truc en tandem avec une ou deux personnes qui utilisent des IDE différents du tien, tu fais comment pour que vos fichiers ".proj" ou ".eclipse" ou ".cbp" soient synchro sans que ça risque de faire clasher vos configs perso ? Et si un nouveau arrive sur le projet avec un quatrième outil encore différent, il doit tout reconstruire à la main ?

Je ne dis évidemment pas que "Vim est le meilleur". Je dis simplement que la solution que j'emploie a énormément de bénéfices, et j'explique pourquoi j'ai adopté cette solution, pourquoi aucun IDE graphique ne saurait répondre à mes besoins, et surtout, pourquoi il faut arrêter d'en avoir peur en mystifiant ces outils.

Tu décris très bien ton contexte, et je suis sûr que tu as choisi les bons outils qui vont avec.

Mais heureusement la vie des amateurs (au double sens de "ceux-qui-aiment" et de "ceux-qui-font-sans-être-payés" ) est loin d'être aussi difficile. On a le temps de s'habituer à un Linux donné (je suis avec Mint13 après mandriva, opensuse, centos, debian et ubuntu)... et d'en changer le jour où il ne fait plus ce qu'on veux. Et puis il y a le multimédia: le plaisir de regarder une vidéo, d'écouter un MP3 ou la radio internet (j'écoute frequence3 en ce moment). Regarder ses photos et les retoucher avec gimp. Fabriquer des livres photos et des calendriers avec la photos des proches. Naviguer sur internet (news, google maps, youtube, et même intervenir dans des forums!), consulter ses emails, participer à des chats, etc... Et de temps en temps (un peu trop souvent d'après ma femme) faire des programmes Python avec des outils graphiques. Bref: ce qu'un ordinateur normal est capable d'apporter à chacun comme service et comme plaisir. Dans un tel contexte, la console a une place minuscule...

Pardon, c'est pas un topic sur les environnements de développement, là ?

Bien sûr, pour du multimédia ou de la retouche photo, tu ne vas pas faire ça en console (quoique, si tu veux multiplexer un photo montage en 3 secondes en le liant à ta musique préférée, une seule ligne te permet de faire ça avec ffmpeg), mais là on parle quand même de l'environnement que l'on utilise pour développer, et pas de l'utilisation lambda d'un ordinateur, non ?

Citation : Malikemal

Effectivement, nous serons tous d'accord pour dire que le shell est beaucoup plus puissant. Mais, pour un membre du Sdz, qui n'est vraisemblablement pas un professionnel (prenons large, 80% des inscrits au moins) ne serait-ce pas plus simple et plus agréable (faut le dire c'est blasant quand on commence de voir un écran noir ...) d'utiliser un IDE graphique ? Surtout que ce que l'on fait c'est pour le plaisir, on est pas spécialement pressé et donc pas forcé d'optimiser notre temps dédié au développement.
Après je ne dis pas qu'il faut forcément jeter le shell quand on est pas pro, mais que dire "Vim est le meilleur" (je ne dis pas que tu l'a dit nohar ) est vrai dans un contexte donné, et encore.

Si c'est que ça, tu peux mettre la console sur un fond blanc hein !
Non mais franchement, je rejoint nohar. Les ide sont souvent présentés comme le saint grall. Mais pourquoi ? parce qu'ils reprennent sous une meme fenetre tout un tas de trucs ? C'est ça votre idéal ? il suffit que tout soit regroupé sous la même fenetre ?

En fait je ne vois pas ce qu'il y a de plus compliqué a avoir une fenetre avec vim, une console pour lancer ces make/cmake/wathever, une autre pour faire ces commit. Le problème est selon moi que les gens ont peur de la console et des outils en lignes de commande. Pourtant quand on commence à les utiliser, on se rend compte que c'est en général super simple à utiliser. tu as l'aide qui est dispo en faisant man, c'est plus compliqué que taper sur F1 ? faire un git commit -m "blabla" c'est plus compliqué que de faire apparaitre 3 fenetre pour commiter des changements ?

Je pense surtout que les gens sont rassurés de voir une belle usine a gaz qui regroupe tout. C'est plus reposant pour le cerveau vu qu'il n'y a pas a choisir les outils. C'est vrai que la console necessite de s'y interesser. Mais franchement c'est plus une peur qu'un problème réel de complexité.

Même gdb, en général pour le debugage je l'utilise en ligne de commande. ça va 10 fois plus vite que d'utiliser une armada intégré dans 95% des cas

Citation : nohar

Pardon, c'est pas un topic sur les environnements de développement, là ?

Ça va avec: quand on utilise l'ordinateur comme je viens de le décrire, on ne repasse pas en console pour développer.

C'est au moins mon avis. Mais tu n'es pas obligé de le partager.

Bon. Avec l'intervention de kristofjé, j'ai l'impression d'avoir énervé les fanas de la console: j'arrête parce que ce genre de discussion n'aboutit jamais.

Citation : kristofjé

Même gdb, en général pour le debugage je l'utilise en ligne de commande. ça va 10 fois plus vite que d'utiliser une armada intégré dans 95% des cas

Le seul truc qui manque à vim nativement à mon goût (enfin ça existe, ça s'appelle clewn, mais ça nécessite de recompiler Vim), c'est un moyen de l'interfacer avec gdb pour pouvoir suivre le code dans ton éditeur en même temps que tu le débugges avec gdb.

Ça, c'est un truc potentiellement très pratique, seulement le fait que ça nécessite de recompiler Vim à la main me freine (je développe constamment sur plusieurs machines en parallèle via SSH, donc je vais pas recompiler Vim sur chacune...), et une fois que l'on sait afficher le listing du code à la main dans gdb, ça n'est pas réellement handicapant. D'autant que ce n'est pas non plus tous les jours que j'ai besoin d'un debugger…

Tiens, encore un autre truc : y'a-t'il un seul IDE graphique qui intègre nativement Valgrind ? Plus généralement, existe-t'il un outil graphique standard taillé exprès pour détecter les fuites de mémoire dans un code ?

Edit :

Citation : tyrtamos

Citation : nohar

Pardon, c'est pas un topic sur les environnements de développement, là ?

Ça va avec: quand on utilise l'ordinateur comme je viens de le décrire, on ne repasse pas en console pour développer.

Heu... si ?
Qu'est-ce qui t'empêche d'avoir ta console avec ton screen sur un bureau virtuel, et Chrome avec la doc sur un autre ? Dans mon cas, c'est même ma console sur un écran, et le navigateur sur l'autre, dans la même session Unity. Avec en parallèle mon client mail graphique, un client VLC graphique pour faire tourner de la musique, et les popups de la libnotify (donc, graphiques) chaque fois que je reçois un mail...

Je n'ai jamais parlé de se passer des interfaces graphiques pour tout, il ne faut pas pousser ! Simplement, je n'ai vu strictement aucun argument sérieux en défaveur de l'utilisation de l'interface en ligne de commande là où elle est réellement puissante : le développement en particulier.

mais non, ce n'etais pas ennervé, je defend mon point de vue, c'est tout !

C'est vraiment de l'incomprehension? J'ai testé et utilisé un paquet d'ide mais j'en reviens toujours à une série de console. Et tu parle d'ordinateur pour du graphisme et multimedia, ça n'empeche pas !
Pour te dire mon environnement de travail c'est un PC avec 2 ecrans de 24" et je travail sur du traitement video. donc forcément j'ai des outils graphique. Mais pour le dev, je n'ai rien trouvé de plus pratique que la majorité des outils consoles.

Evidement si j'ai a retouché une image, j'ouvre gimp, mais pour le dev, apres en avoir testé beaucoup, j'ai toujours trouvé les outils directement en console plus simple, c'est tout

Pourquoi je recommande geany comme "truc" pour booser en Python :
(c'est ça la question de départ, non ? !!! )

J'ai commencé avec GEdit, mais,

1) lorsqu'on lance un script qui bloucle à l'infini, il est plus délicat de tuer son appli, avec geany, ça marche. 1-0

2) lorsqu'on a une ligne gigantesque (un big tableau sur une ligne),
oui je sais c'est pas bien, mais ça m'arrive souvent.
GEdit rame à mort avec un gros fichier et bugg un peu sur les grandes lignes.
Geany ne bronche pas. 2-0

2 bis) Lancer un script avec Geany c'est F5, et pi c tout. Avec GEdit, il faut éditer un fichier de préparation. 3-0.

3) Geany répond à tous mes autres besoins, qui sont modestes, comme le fait GEdit (sauf les points nommés précédemment).

4) Je ne suis pas développeur, ni professionnel, juste un type qui aime tordre des problèmes d'algo. Je n'ai pas besoin de plus, tout comme n'importe qui qui débuterai la programmation.
Je pense que pour un débutant, il faut rester avec un outil simple, un "truc" (EDI, ou éditeur de texte, on s'en ...) qui reste basique.
C'est donc ce genre d'éditeur que je recommande à 200%.

Proposer Vim ou Emacs à des lycéens pour une classe d'algo est àmha simplement barjo !!! (Mais je concède que ce sont les meilleurs pour les pro)

5) Geany est multiplateforme : Windows et GNU/Linux. ( Mac ??? )
Attention sous KDE des difficultés ont été rapportées. (mais qui utilise donc kde ??? <humour> )

6) Évidemment, Geany propose une belle coloration syntaxique, facilement modifiable (très important pour moi).
Indentation auto, ... et tout les trucs classiques.
La complétion, j'aime pas non plus, ça se désactive tout seul.
On fait comme on veut.

-----

Conclusion, dans la catégorie léger, pour débutant, (même pour les bons)
je ne vois rien de meilleur que Geany.

--
et je peut concevoir que notepad++ soit bon aussi, mais pas multiplateforme, pas linux (donc je ne connais pas du tout).
Je conçois aisément que Vim et autre Emacs soient les boss à un autre niveau.

---

Avis tranché, à la hache, comme d'hab.

---

Je n'ai pas vu beaucoup de post répondant à la charte demandé par le PO.

Citation

Proposer Vim ou Emacs à des lycéens pour une classe d'algo est àmha simplement barjo !!! (Mais je concède que ce sont les meilleurs pour les pro)

Pourquoi "pour les pros" ? Soit on est lycéen, soit on est pro ? Ce site regorge de gens qui apprennent à programmer pour bosser sur des projets, par loisir ou simplement par goût. Seulement du moment où tu commences à bosser sur un projet, l'utilisation d'outils adaptés devient intéressante.

Alors bien sûr, pour le petit script que tu fais en classe d'algo ou pour un concours, le bénéfice d'une solution puissante ne se fait pas ressentir, mais du moment où tu commences à développer un soft qui ne soit pas un one-shot, et qui te demande potentiellement de le maintenir, ou que tu veux le faire grossir (nul besoin d'être un pro pour ça, heureusement !), là, par contre, Vim et Emacs deviennent pertinents, voire très pertinents si en plus tu ne comptes pas t'arrêter là dans ton utilisation de Linux.

En fait, je trouve ça dommage de lire ce "pour les pros". C'est très décourageant, et c'est pour moi signe d'un complexe qui n'a pas lieu d'être. Je suis un dev enthousiaste avant d'être un pro, et je n'ai pas attendu de développer sous Linux pour mon travail avant d'utiliser ces solutions... (Eh oui, avant j'étais sous Windows au taff... eh ben j'ai quand même très vite utilisé Vim sous Windows pour mes scripts, même si je me sentais vraiment à poil sans shell à côté)

PS : Ctrl + C pour killer une boucle infinie, passage automatique à la ligne au bout de 79 caractères (paramétrable) et mise en forme des gros tableaux avec l'indentation auto, :!./nom_du_script.py (autocomplété) pour le lancer. 3 partout.

Haha ça commence à troller !

(Je ne parle pas de Vim vu que je ne connais pas... Mais je n'ai rien contre hein !)

Citation

1) lorsqu'on lance un script qui bloucle à l'infini, il est plus délicat de tuer son appli, avec geany, ça marche. 1-0

Euh... lol ? Emacs Ctrl-C, merci.

Citation

2) lorsqu'on a une ligne gigantesque (un big tableau sur une ligne),
oui je sais c'est pas bien, mais ça m'arrive souvent.
GEdit rame à mort avec un gros fichier et bugg un peu sur les grandes lignes.
Geany ne bronche pas. 2-0

Jamais vu Gedit bronchait là dessus mais bon, n'importe quel bon éditeur le supporte...

Bon je passe les autres trucs...

Citation

Conclusion, dans la catégorie léger, pour débutant, (même pour les bons)
je ne vois rien de meilleur que Geany.

Geany, léger ? On aura tout vu...

Citation

et je peut concevoir que notepad++ soit bon aussi, mais pas multiplateforme, pas linux (donc je ne connais pas du tout).
Je conçois aisément que Vim et autre Emacs soient les boss à un autre niveau.

La question fatidique : Pourquoi Geany serait-il plus facile à utiliser que Emacs (ou Vim) ?

J'ai commencé à coder sous Emacs, avec la version graphique, en cliquant sur les menus comme dans Notepad++ ou Geany, puis je me suis très vite rendu compte que les raccourcis c'était pas mal...

On parle d'étudiant en informatique, bah comment gagner 10 minutes sur un partiel ? Apprendre les raccourcis Emacs / Les commandes bashs...

Emacs (et Vim ?) possède un environnement graphique qui le rend aussi simple d'utilisation que n'importe quel éditeur quand on débute, et qui permet de s'habituer petit à petit aux fonctions avancées...

C'est quand même beaucoup plus rapide de taper des cd, etc... Avec nos bashs actuels (qui ne sont pas ceux des années 70 non... ) que de faire du clicodrome.

Je pousserais même le vice plus loin : Je suis un Windoxiens affirmé, je n'ai plus Linux sur ma machine et dès que je code du Python (et certains autres langage), j'ouvre ma commande DOS et Emacs (oui Emacs existe sous Windows... ).