Discussion :

[Mickael_Istria]

Gratuit, Léger (je n'aime pas Eclipse et sa lenteur)

Il ne faut pas confondre legerete et vitesse percue. Si tu regardes la consommation RAM et CPU de VSCode (et des processes enfants qu'il demarre), t'es souvent proche de ce que fait Eclipse IDE. La difference est que VSCode a mis de l'UI asynchrone la ou Eclipse IDE a tendance a etre synchrone; si bien qu'une operation longue dans Eclipse IDE ca fait parfois un lag, dans VSCode, ca fait une fenetre vide qui se peuple de maniere asynchrone sans te bloquer.
Pour info, Eclipse IDE prend aussi la direction de l'asynchrone pour la plupart des operations de base telles que la completion.

[YCL-1]

J'utilise PyDev couplé à Eclipse pour le travail mais je dois dire que je regrette un peu ce choix.
D'une la configuration d'origine est très déroutante pour les utilisateurs de Windows, c'est peut-être idiot comme argument mais devoir passer des heures à configurer un IDE ça décourage facilement, les raccourcis, les préférences d'exécutions, et la tonne de modules qu'on/je n'utiliserai jamais.

L'impossibilité (d'après mon expérience là dessus) de pouvoir configurer en masse les scripts d'un même projet, l'exécution en run plutôt qu'en debug par exemple.

L'export/import de configuration ne comprend pas celui de PyDev et ce n'est pas la peine d'essayer de regarder les fichiers xml de configurations il y en des milliers et tous sont référencés par des fichiers de configuration mère, autant dire que c'est humainement impossible à modifier.

Je regrette que PyDev/Eclipse ne puisse pas permettre l'interception de l'arrêt d'un script avec par exemple le raise d'un KeyboardInterrupt comme sait le faire le très léger PyScripter. Je sais qu'il existe un moyen pour avoir vu un sujet sur StackOverflow mais impossible de mettre la main dessus.

Et que dire de l'exécution d'un script précédemment fermé lorsque que Eclipse ne détecte pas le script qu'on vient d'ouvrir, c'est très fâcheux comme fonctionnalité.

[Voconce]

ainsi qu'idle quelquefois...

[bacargoudiaby]

Je dirais que Sublime text est le meilleur

[Invité]

Mon préféré c'est IDLE, son fenêtrage est basique et sa simplicité facilite une écriture mieux concentrée. En fait, on remarque l'inutilité de certains gadgets, même du point visuel, cet outil sans le vouloir nous intrigue. Tout en étant inutile dans le travail en cours, il se pourrait qu'à un moment donné le code ait besoin d'un idéal se rapprochant de son effectif. Comme quoi on est vite perdu lorsque ça devient compliqué, alors la simplicité a du bon. Python aussi. En utilisant Pycharm, on se retrouve en compagnie d'un correcteur tuteur, rectificateur avant la chute libre de la concentration et de son évaporation. On comprend ainsi que la programmation est un loisir impeccable, mais quand l'élémentaire nous éloigne du complexe de fabrique, lorsque certains gestes à répétition font cette triste joie :

On arrive aux "print", ceux utiles à la visibilité des données de définition à contrôler, une mise en oeuvre laborieuse, et autant pour blanchir l'affichage en y ajoutant les # de blocage.

Ceci n'est qu'un exemple basique

Imaginons maintenant que notre éditeur offre le choix de créer des thèmes de blanchiment, de travailler avec les print et les # de manière thématique ?

Cette histoire de print a un niveau qui va au-delà de mes compétences et occupations
Raison du message

[wiztricks]

Salut,

On comprend ainsi que la programmation est un loisir impeccable, mais quand l'élémentaire nous éloigne du complexe de fabrique, lorsque certains gestes à répétition font cette triste joie :

On arrive aux "print", ceux utiles à la visibilité des données de définition à contrôler, une mise en oeuvre laborieuse, et autant pour blanchir l'affichage en y ajoutant les # de blocage.

Ceci n'est qu'un exemple basique

Imaginons maintenant que notre éditeur offre le choix de créer des thèmes de blanchiment, de travailler avec les print et les # de manière thématique ?

Cette histoire de print a un niveau qui va au-delà de mes compétences et occupations

Les programmeurs évitent les tâches répétitives.
Au lieu de mettre en commentaire les "print" de debug, ils vont fabriquer une fonction qui fera la même chose que "print" sous la condition d'un booléen DEBUG.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def debug(*args, ***kwds):
      if DEBUG:
         print(*args, **kwds)

lorsque la mise au point est terminée, peut être qu'il n'est pas pertinent de mettre en commentaires ou supprimer toutes les lignes debug(...) mais l'éditeur sait faire des remplacement conditionnels ou globaux (même IDLE) et on va pouvoir remplacer ceux là (et non les autres "print").

Les programmeurs partagent leurs bonnes idées.
C'est pour cela qu'il y a plein de bibliothèques en standard dans Python. Le module logging est une version un peu plus élaborée de la fonction "debug" qu'on peut écrire pour dépanner et contient bien d'autres fonctionnalités intéressantes.

- W

[Invité]

Mon point de vue est différent, les "print" de mon cas affichent des résultats à chaque répétition afin de m'assister dans le développement. De plus il est intéressant d'y voir les effets des opérations en cours, car composer une logique opératoire lorsqu'on remplace le papier par un écran. Il n'y a qu'à réfléchir sans perdre son temps avec le crayon et la gomme. Sans l'affichage des "print" on est voué a un laborieux calcul (mental, papier, écran), et pour les nombres communs ces informations sont pertinentes. Il n'y a pas de mystère puisque le sujet de la multiplication est implacable, tout comme les gammes musicales il traite une structure logique. Il est nécessaire d'informer sur les causes du déploiement multiple, ne serait-ce que par simple curiosité.
Les commentaires ne sont pas un luxe, surtout en comparaison avec la valeur affichée. Tout comme si les aiguilles représenteraient le code, et les repères seraient les résultats, et l'annonce un commentaire

Je vais essayer l'idée de ceci, dans l'esprit du ci-dessus (no debug)(ok dico) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Voici un exemple de chaîne de documentation multi-lignes :
>>>
>>> def my_function():
...     """Do nothing, but document it.
...
...     No, really, it doesn't do anything.
...     """
...     pass
...
>>> print(my_function.__doc__)
Do nothing, but document it.
    No, really, it doesn't do anything.

[Invité]

Je vais essayer l'idée de ceci, dans l'esprit du ci-dessus (no debug)(ok dico) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Voici un exemple de chaîne de documentation multi-lignes :
>>>
>>> def my_function():
...     """Do nothing, but document it.
...
...     No, really, it doesn't do anything.
...     """
...     pass
...
>>> print(my_function.__doc__)
Do nothing, but document it.
    No, really, it doesn't do anything.

Mais, j'aurais bien voulu disposer d'un outil qui me permette de créer un suivi (voir plus) du code en cours. Que l'IDLE ait cet outil ! Afin de ne pas avoir cette charge à ajouter dans la programmation, déjà qu'il est pratiquement impossible de tout savoir au départ

[Le gris]

je crois que VSCode a été oublier. Et pourtant à l'heure actuelle, c'est un des meilleurs EDI

[disedorgue]

je crois que VSCode a été oublier. Et pourtant à l'heure actuelle, c'est un des meilleurs EDI

Disons qu'au bout de 3 ans, il y a eu quelques changements...

[phantom1999]

Spyder et jupiter notebook

[scalpel]

Bonjour à tous.tes,

Je suis débutant en programmation, j'ai juste un mois de pratique du langage Python.
J'utilise "Visual Studio Code V1.85.2" sous "Windows 11" avec les extensions "Python et Pylance".

Ne voyant pas cet IDE dans les propositions du sondage, je me demande si j'ai fait le bon choix.

[papajoker]

bonjour

me demande si j'ai fait le bon choix.

Cette demande a été faite il y a 3 messages avant toi...

Actuellement, c'est un choix des plus populaire (je le suppose dans le top 3) donc, si nous ne sommes pas tous des moutons, possiblement un bon choix.

[scalpel]

bonjour

Cette demande a été faite il y a 3 messages avant toi...

Actuellement, c'est un choix des plus populaire (je le suppose dans le top 3) donc, si nous ne sommes pas tous des moutons, possiblement un bon choix.

Bonjour,

Avant de poster, j'avais bien consulté une grande partie des messages de ce sondage.
Compte tenue de mon niveau actuel, savoir si c'est le meilleur ou pas des IDE pour Phyton ne m'intéresse pas pour le moment.
Je voulais savoir si il était le plus adapté aux débutants en programmation, je n'ai probablement pas les mêmes attentes qu'un "membre averti" ou un "expert confirmé".

J'aimerai par exemple un EDI qui me permette un accès direct aux références (syntaxe) du langage.

Cordialement.

[jurassic pork]

Hello,
ben flute alors je viens de m'apercevoir que l'EDI que j'utilise maintenant n'avez aucun vote, alors j'ai voté pour lui. Il s'agit de Thonny. Les puristes me diront qu'il est pas complet mais pour un débutant ou quelqu'un qui fait des essais comme moi, il est suffisant :
1 - très léger , facile à installer et facile à utiliser
2 - Un python récent embarqué
3 - Editeur de code. Console
3 - Un gestionnaire de paquets
4 - Un débogueur avec visualisation des variables.
5 - Un inspecteur d'objets
5 - Multiplateforme (windows Mac Linux) - Multilangue (dont le français)

Ami calmant, J.P